优化SQLite很棘手.C应用程序的批量插入性能可以从每秒85次插入到每秒超过96,000次插入!
背景:我们使用SQLite作为桌面应用程序的一部分.我们有大量的配置数据存储在XML文件中,这些数据被解析并加载到SQLite数据库中,以便在初始化应用程序时进行进一步处理.SQLite非常适合这种情况,因为它速度快,不需要专门配置,数据库作为单个文件存储在磁盘上.
理由: 最初我对我所看到的表现感到失望.事实证明,SQLite的性能可能会有很大差异(对于批量插入和选择),具体取决于数据库的配置方式以及如何使用API.弄清楚所有选项和技术是什么并不是一件小事,所以我认为创建这个社区wiki条目以与Stack Overflow读者分享结果是谨慎的,以便为其他人节省相同调查的麻烦.
实验:我不是简单地谈论一般意义上的性能提示(即"使用事务!"),而是认为最好编写一些C代码并实际测量各种选项的影响.我们将从一些简单的数据开始:
我们来写一些代码吧!
代码:一个简单的C程序,它逐行读取文本文件,将字符串拆分为值,然后将数据插入SQLite数据库.在代码的这个"基线"版本中,创建了数据库,但我们实际上不会插入数据:
/*************************************************************
Baseline code to experiment with SQLite performance.
Input data is a 28 MB TAB-delimited text file of the
complete Toronto Transit System schedule/route info
from http://www.toronto.ca/open/datasets/ttc-routes/
**************************************************************/
#include <stdio.h>
#include <stdlib.h>
#include <time.h>
#include <string.h>
#include "sqlite3.h"
#define INPUTDATA "C:\\TTC_schedule_scheduleitem_10-27-2009.txt"
#define DATABASE "c:\\TTC_schedule_scheduleitem_10-27-2009.sqlite"
#define …我花了一些时间专门为数据库和SQLite阅读不同的最佳实践.在阅读时我发现我做了很多我不应该做的事情,在尝试修复这些问题时,我在考虑使用SQLite及其ADO实现的一些更精细的细节时感到困惑.
我的困惑源于准备好的陈述和连接池.
在阅读http://msdn.microsoft.com/en-us/library/ms971481.aspx时,我发现只应为事务打开连接.交易完成后,应关闭连接.我没有牢牢掌握为什么会这样,但我一直在假设作者知道的比我更好.我明白当连接关闭时并不意味着它实际上已经存在已经关闭.它只是意味着它已被放回池中.
现在,为了改进我的查询和插入,我阅读了有关使用预准备语句 在SQLite中,准备好的语句真的能提高性能吗？和http://petesbloggerama.blogspot.com/2007/02/sqlite-adonet-prepared-statements.html似乎都表明,当执行多次执行的查询时,准备好的语句是可行的.我还读过,预准备语句特定于连接,并且一旦连接关闭,预准备语句就会丢失.
我的困惑是这个.如果我打开和关闭我的连接(可能或不可能意味着由于线程池而关闭连接)那么我从准备好的声明中获得了多少用处？我可以理解,如果我有1000个对象,我需要在单个事务中保存,准备好的语句可以帮助很多.但是我不相信我会看到在事务中保存单个对象会带来好处,因为一旦我关闭了连接,从第一个对象生成的预准备语句现在就会丢失.这是真实的陈述吗？
我相信准备好的语句与我的SQLiteCommand对象的范围有关,这进一步加剧了我的困惑.
如果我创建一个表示我将经常执行的查询的SQLiteCommand,我是否需要将SQLiteCommand保留在内存中以使预准备语句保持活动状态？
如果我用相同的SQLite语句创建一个新的SQLiteCommand,它是否认识到新的SQLiteCommand与前一个相同,因此有一个可以使用的预准备语句？
如果我在内存中保留一个SQLiteCommand并更改它的参数和连接,因为我打开并关闭不同事务的连接,我基本上在不同的连接之间保持一个准备好的语句？
我很可能在这一点上思考问题,但我希望你能帮助我更好地理解这些事情是如何相互作用的,这样我才能从中获益最多.
我需要检索与列表中存储的ID匹配的记录.在运行时生成的查询很简单:
SELECT [whatever FROM sometable] WHERE (id = 1) or (id = 5) or (id = 33).
这相当于
SELECT [whatever FROM sometable] WHERE [id] IN (1, 5, 33);
这很好,但如果列表包含数百或数千个ID怎么办？声明将是巨大的,并且在某些时候SQL解析器可能会呱呱叫,或者如果它没有,性能可能会非常糟糕.如何以对检索的记录数量不那么敏感的方式执行此操作？
(我不能只循环遍历列表并逐个检索记录的原因是我需要数据库为我做ORDER BY.记录必须来自特定字段排序的数据库,而列表表示由网格中的用户可以通过多种方式进行排序.是的,我可以在检索后对代码中的记录进行排序,但这是计划B,因为我甚至不需要将它们全部保存在一个数据结构中,只是为了正确订购.)