SQLLite操作百万级数据之优化篇
描述:SQLite数据库本质上来讲就是⼀个磁盘上的⽂件,所以⼀切的数据库操作其实都会转化为对⽂件的操作,⽽频繁的⽂件操作将会是⼀个很耗时的过程,会极⼤地影响数据库存取的速度。
描述:
SQLite本质上来讲就是⼀个磁盘上的⽂件,所以⼀切的数据库操作其实都会转化为对⽂件的操作,⽽频繁的⽂件操作将会是⼀个很耗时的过程,会极⼤地影响数据库存取的速度。例如:向数据库中插⼊100万条数据,在默认的情况下执⾏相应的操作,就会打开和关闭⽂件100万次,所以速度当然会很慢。
分析:
sql语句优化方式在⼊库和更新过程中按照数据库事务的思想进⾏设计:SQLite执⾏⼊库、更新操作的⽅式是,语句执⾏对象句柄调⽤库函数打开⽂件、调⽤函数执⾏、关闭⽂件。这样的执⾏⽅式对于数量级别超⼤的⽂件的弊端就是每次执⾏sql语句的时候都要打开⽂件(假设百万级数量级的数据,就要打开和关闭⽂件百万次),对于数据库的⼊库和更新操作时间主要都浪费到了⽂件的打开和关闭操作上,所以这⾥增加事务以解决该问题.
解决:
SQLite数据库是⽀持事务操作的,于是我们就可以通过事务来提⾼数据库的读写速度。事务的基本原理是:数据库管理系统⾸先会把要执⾏的sql语句存储到内存当中,只有当commit()的时候才⼀次性全部执⾏所有内存中的数据库。同时,在.NET中对数据的操作还可以采⽤预编优化的⽅式来提升性能,这种⽅式是采⽤IDbCommand的Prepare⽅法来进⾏的。
B、代码环境
NET2.0、Access2003、Firebird 2.1.1.17910、SQLite 3.6.3
Firebird Data Provider(FirebirdSql.Data.FirebirdClient.dll, 2.1.0.0)
SQLite Data Provider(System.Data.SQLite, 1.0.60.0)
下是测试数据,仅予参考
测3次平均,⽆测10W+,因Firebird出现OutMemoryException
⽆测修改操作,因⽆需求
依序 1、10、100、1000、10000 条数据,单位 ms
新增操作
1.⽆预编, ⽆事务
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事务⽀爰不强,但预编启性能很好
SQLite缺省已预编,加上事务控制性能更好
Access查询加排序,数据10W+时性能极差(I/O问题)
单测Firebird 10W+新增操作,性能极差(I/O问题)
10W+数据操作性能多卡在I/O,不过SQLite因规格单纯,所以性能会较强
总结:
1.通过事务⼀次提交多条SQL语句,以减少SQLLite数据的IO操作,可以有效提升⼤数据量操作的性能。
2.通过.NET中的预编译优化⽅式,即采⽤IDbCommand的Prepare⽅法来配合事务执⾏⼤批量SQL操作,可以进⼀步优化其性能。
版权声明:本站内容均来自互联网,仅供演示用,请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198,我们将在24小时内删除。
发表评论