也许有人还不知道，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，否则界面会卡死。