解决方案
2
2
莫非大数据处理时,sqlserver 不应该比sqlite快吗? 这个求指导.
同意一楼提出的,sqlserver 能否是本机.
同意一楼提出的,sqlserver 能否是本机.
2
4
SQLITE题主搞清楚适用范围了吗,要求不要太高了,它是一个轻便的小型数据库.
2
sqllite……这么轻型的数据库,你居然要放100万数据……
2
假如你放了100万数据到 sqlite 里边,而且只是按照索引简单匹配(例如 where id=”1234″)并且正确地建立了索引,那么它理应比 SQL Server 会快。不但 Sqlite 会快,就算是 Access(Jet)甚至都会比 SQL Server 更快。嵌入式数据库本来就有这个特点,在数据库很小(例如说只有不到200万记录,只有不到1G数据文件)时做本地查询很快。原因是数据库系统内部的最基本的数据记录的数据结构其实是差不多的。而嵌入式系统少了许多与查询无关的开销,例如少了网络上传送返回结果的巨大开销。
但是假如你需要编译这么复杂的sql表达式,并且你反复测试,那么那些可以自动优化sql表达式、可以自动重复使用编译结果、可以自动分配好几个G的缓存的数据库就肯定会体现出作用来了。而没有编译功能、没有优化功能、不能重用编译结果、不以大量占用内存进行缓存为主的嵌入式数据库肯定力不从心了。
使用嵌入式数据库,你应该本人写算法来进行各种优化过的查询,你应该写100条语句来进行这个查询,而不是写一条复杂的sql语句。
对于sqlite之类的数据库,也确实会“原因是它比SQL Server更快”才使用的(这有大量测试作为证据),但这是有条件的。你只用 sqlite 最好的那一半功能,另外一半功能应该放弃。
但是假如你需要编译这么复杂的sql表达式,并且你反复测试,那么那些可以自动优化sql表达式、可以自动重复使用编译结果、可以自动分配好几个G的缓存的数据库就肯定会体现出作用来了。而没有编译功能、没有优化功能、不能重用编译结果、不以大量占用内存进行缓存为主的嵌入式数据库肯定力不从心了。
使用嵌入式数据库,你应该本人写算法来进行各种优化过的查询,你应该写100条语句来进行这个查询,而不是写一条复杂的sql语句。
对于sqlite之类的数据库,也确实会“原因是它比SQL Server更快”才使用的(这有大量测试作为证据),但这是有条件的。你只用 sqlite 最好的那一半功能,另外一半功能应该放弃。
3
大数据量,高并发的情况下,不建议用sqlite!
当然 在简单的Sql语句下(小数据)还是sqlite快
当然 在简单的Sql语句下(小数据)还是sqlite快
3
关闭事务,完事之后再打开事务,Sqlite就会快了