android - 如何在 Android 中使用 SQLite 获得最佳性能？

Question

我注意到有多种方法可以执行 SQLite 操作(查询、插入、更新、删除)，有些方法可能比其他方法更快。许多网站提供不同的提示，并且有些与其他网站冲突。

1. 似乎使用事务进行批量插入比在循环中这样做要快一些。

   怎么会？使用 SQLite 时获得最佳性能的最佳方法是什么？ sqlite 在 Android 上如何运行？

2. 混淆使用 InserHelper对比ContentValues ，如图here .

   如何InserHelper工作，它会永远比ContentValues快吗？ ？将其与事务包装在一起会进一步加快速度吗？

3. 对其他 SQL 框架的混淆。我记得添加索引会提高与索引相关的查询的性能。 Android 也是如此吗？这是一种好的做法吗？

4. 我听说在某些情况下，最好不要使用 UI 线程进行数据库操作。在哪些情况下推荐这样做？比如，数据库操作会变得多慢？如果 DB 变成 70MB，是否意味着它会慢很多并且 UI 线程永远不应该处理它？<​​/p>

Answer 1

how come?

事务涉及磁盘 I/O。执行一个较大的磁盘 I/O block 比执行许多小的磁盘 I/O block 要便宜得多。

how does the InserHelper work and will it always be faster than contentValues?

引用 the documentation : "此类允许用户对表进行多次插入，但只编译一次 SQL 插入语句，这可能会提高性能。"

will wrapping it with a transaction speed it even further ?

大概是的。

is it true for android too ?

索引可以提高查询速度，如果您为正在执行的任何查询创建适当的索引。索引总是降低插入/更新/删除速度，因为现在需要更新这些索引。这与 Android 无关。

is is a good thing to use ?

这不可能抽象地回答。这与 Android 无关。

it's best to not use the UI thread for DB operations

正确。

in which cases will it be recommended ?

不建议在主应用程序线程上执行任何磁盘 I/O。

how slow could DB operation become ?

几个世纪以来。到那时，设备可能会出现故障，或者电池电量会耗尽。

if the DB becomes 70MB , does it mean that it will be much slower

这取决于你用它做什么。

and UI thread should never handle it ?

正确。