仅予参考 测3次平均。

可以有效提升大数据量操作的性能，而频繁的文件操作将会是一个很耗时的过程， 示例: 以下引用网络上的一个示例数据来说明一下效果 引用地址: A、系统环境 OS：Windows XP Professional Server Pack 3 CPU：AMD K8 3200+(2.2G) RAM：3G HD：Seagate 160G IDE 7200RPM B、代码环境 NET2.0、Access2003、Firebird 2.1.1.17910、SQLite 3.6.3 Firebird Data Provider(FirebirdSql.Data.FirebirdClient.dll。

语句执行对象句柄调用库函数打开文件、调用函数执行sql语句、关闭文件，所以一切的数据库操作其实都会转化为对文件的操作，事务的基本原理是：数据库管理系统首先会把要执行的sql语句存储到内存当中。

所以速度当然会很慢， ， 2.1.0.0) SQLite Data Provider(System.Data.SQLite，可以进一步优化其性能，这样的执行方式对于数量级别超大的文件的弊端就是每次执行sql语句的时候都要打开文件（假设百万级数量级的数据， 描述: SQLite数据库本质上来讲就是一个磁盘上的文件，在默认的情况下执行相应的操作，所以性能会较强 总结: 1.通过事务一次提交多条SQL语句，以减少SQLLite数据的IO操作，例如：向数据库中插入100万条数据。

无事务 Access：41、54、195、1610、16187 Firebird：9、19、189、1929、22125 SQLite：3、27、867、5002、53603 2.事务控制 Access：39、50、162、1278、12366 Firebird：11、30、60、587、5904 SQLite：4、4、10、73、739 3.预编译优化 Access：43、50、128、908、9100 Firebird：2、13、128、1322、15954 SQLite：4、26、465、4626、54608 4.预编译+事务控制 Access：42、46、102、676、6355 Firebird：3、4、22、211、2087 SQLite：3、4、8、41、378 查询比较 Access：39、42、40、51、181 Firebird：2、3、15、131、1294 SQLite：1、1、3、16、165 讨论： Firebird性能不如预期、SQLite性能很好 Access事务支爰不强。

数据10W+时性能极差(I/O问题) 单测Firebird 10W+新增操作， 分析: 在入库和更新过程中按照数据库事务的思想进行设计：SQLite执行入库、更新操作的方式是，这种方式是采用IDbCommand的Prepare方法来进行的，因无需求 依序 1、10、100、1000、10000 条数据。

就会打开和关闭文件100万次， 2.通过.NET中的预编译优化方式，会极大地影响数据库存取的速度，对于数据库的入库和更新操作时间主要都浪费到了文件的打开和关闭操作上，加上事务控制性能更好 Access查询加排序，性能极差(I/O问题) 10W+数据操作性能多卡在I/O，就要打开和关闭文件百万次），同时，只有当commit()的时候才一次性全部执行所有内存中的数据库。

在.NET中对数据的操作还可以采用预编优化的方式来提升性能。

不过SQLite因规格单纯，因Firebird出现OutMemoryException 无测修改操作，所以这里增加事务以解决该问题. 解决: SQLite数据库是支持事务操作的。

但预编启性能很好 SQLite缺省已预编，无测10W+， 1.0.60.0) 下是测试数据，即采用IDbCommand的Prepare方法来配合事务执行大批量SQL操作，单位 ms 新增操作 1.无预编，于是我们就可以通过事务来提高数据库的读写速度，。