也許有人還不知道，Android 是有一些內建的 類庫支持 SQL Lite 數據庫的操作。他提供了一個很好的方式在 Android 上組織少量的數據。不管怎樣，在使用這些類庫的時候有一些陷阱是需要注意的。

根據你所使用的版本不同，一個相同的查詢的運行時間可能從幾毫秒到幾分鐘不等。例如，一個查詢可能在 Galaxy S2 運行少于一秒（在 iPhone 4 上可能更快），但是在 Atrix 2 和 HTC Desire 上運行卻需要一分鐘。所有這些手機都有類似的硬件，那么區別在哪里？

在對代碼研究了幾天后，我發現問題在于查詢語句的設計。當你使用大量的 joins 或者 unions 的時候，問題就出現了。組合一張大的數據表和一張或多張中等大小的數據表，需要非常小心的優化來保證在所有的設備上都有良好的性能。在做 unions 或者 joins 之前限制數據表的大小很重要！

我們以下面的數據庫和數據表為例：

• 一張 Person 表，有 name, height, age 等字段
• 一張 Family 表，包含了家庭的詳情
• 一張 City 表，包含了所有城市的信息

在 Android 上面把所有這些表聯合起來（假設 Person 表有超過2000條記錄）在大部分設備上是沒有問題的。但是假如你的用戶正在使用一個老版本的 SQL Lite 版本，你的應用就慢的無法使用了。你要盡量讓 join 的記錄越少越好以保證性能。例如，你從 Person 表中抽取一部分記錄再做 join，性能就會好很多。

這里的難點是如何知道用戶使用的是什么版本的 SQL Lite。雖然 Android 有一個默認的版本，但是似乎不同的廠商在不同的設備上用了不同的 SQL Lite 版本。這就給我們造成了很大的麻煩。

在 StackOverFlow 上有一些關于這方面的信息。總之嘗試去獲得設備的 SQL Lite 版本是很困難的，你最好還是把力氣花在優化 SQL 上面，以保證在所有的設備上都有良好的性能。

還有一個有趣的地方就是 Android 上面，一條查詢究竟是何時被執行的。也許你認為當你獲得 Cursor 對象的時候，查詢就執行完了。但事實情況是，查詢不會被執行直到 Cursor 被第一次訪問，例如 moveToNext，moveToFirst 操作。所以請不要在 UI 線程或者相關的線程中使用 cursor，否則界面會卡死。