SQLite的查询优化
SQLite是个典型的嵌入式DBMS,它有很多优点,它是轻量级的,在编译之后很小,其中一个原因就是在查询优化方面比较简单,它只是运用索引机制来进行优化的,经过对SQLite的查询优化的分析以及对源代码的研究,我将SQLite的查询优总结如下:
一、影响查询性能的因素:
1. 对表中行的检索数目,越小越好
2. 排序与否。
3. 是否要对一个索引。
4. 查询语句的形式
二、几个查询优化的转换
1. 对于单个表的单个列而言,如果都有形如T.C=expr这样的子句,并且都是用OR操作符连接起来,形如: x = expr1 OR expr2 = x OR x = expr3 此时由于对于OR,在SQLite中不能利用索引来优化,所以可以将它转换成带有IN操作符的子句:x IN(expr1,expr2,expr3)这样就可以用索引进行优化,效果很明显,但是如果在都没有索引的情况下OR语句执行效率会稍优于IN语句的效率。
2. 如果一个子句的操作符是BETWEEN,在SQLite中同样不能用索引进行优化,所以也要进行相应的等价转换: 如:a BETWEEN b AND c可以转换成:(a BETWEEN b AND c) AND (a>=b) AND (a<=c)。 在上面这个子句中, (a>=b) AND (a<=c)将被设为dynamic且是(a BETWEEN b AND c)的子句,那么如果BETWEEN语句已经编码,那么子句就忽略不计,如果存在可利用的index使得子句已经满足条件,那么父句则被忽略。
3. 如果一个单元的操作符是LIKE,那么将做下面的转换:x LIKE ‘abc%’,转换成:x>=‘abc’ AND x<‘abd’。因为在SQLite中的LIKE是不能用索引进行优化的,所以如果存在索引的话,则转换后和不转换相差很远,因为对LIKE不起作用,但如果不存在索引,那么LIKE在效率方面也还是比不上转换后的效率的。
三、 几种查询语句的处理(复合查询)
1.查询语句为:<SelectA> <operator> <selectB> ORDER BY <orderbylist> ORDER BY
执行方法: is one of UNION ALL, UNION, EXCEPT, or INTERSECT. 这个语句的执行过程是先将selectA和selectB执行并且排序,再对两个结果扫描处理,对上面四种操作是不同的,将执行过程分成七个子过程:
outA: 将selectA的结果的一行放到最终结果集中
outB: 将selectA的结果的一行放到最终结果集中(只有UNION操作和UNION ALL操作,其它操作都不放入最终结果集中)
AltB: 当selectA的当前记录小于selectB的当前记录
AeqB: 当selectA的当前记录等于selectB的当前记录
AgtB: 当selectA的当前记录大于selectB的当前记录
EofA: 当selectA的结果遍历完
EofB: 当selectB的结果遍历完
下面就是四种操作的执行过程:
执行顺序 |
UNION ALL |
UNION |
EXCEPT |
INTERSECT |
AltB: |
outA, nextA |
outA, nextA |
outA,nextA |
nextA |
AeqB: |
outA, nextA |
nextA |
nextA |
outA, nextA |
AgtB: |
outB, nextB |
outB, nextB |
nextB |
nextB |
EofA: |
outB, nextB |
outB, nextB |
halt |
halt |
EofB: |
outA, nextA |
outA, nextA |
outA,nextA |
halt |
2. 如果可能的话,可以把一个用到GROUP BY查询的语句转换成DISTINCT语句来查询,因为GROUP BY有时候可能会用到index,而对于DISTINCT都不会用到索引的 。
四、子查询扁平化
例子:SELECT a FROM (SELECT x+y AS a FROM t1 WHERE z<100) WHERE a>5
对这个SQL语句的执行一般默认的方法就是先执行内查询,把结果放到一个临时表中,再对这个表进行外部查询,这就要对数据处理两次,另外这个临时表没有索引,所以对外部查询就不能进行优化了,如果对上面的SQL进行处理后可以得到如下SQL语句:SELECT x+y AS a FROM t1 WHERE z<100 AND a>5,这个结果显然和上面的一样,但此时只需要对
数据进行查询一次就够了,另外如果在表t1上有索引的话就避免了遍历整个表。
运用flatten方法优化SQL的条件:
1.子查询和外查询没有都用集函数
2.子查询没有用集函数或者外查询不是个表的连接
3.子查询不是一个左外连接的右操作数
4.子查询没有用DISTINCT或者外查询不是个表的连接
5.子查询没有用DISTINCT或者外查询没有用集函数
6.子查询没有用集函数或者外查询没有用关键字DISTINCT
7.子查询有一个FROM语句
8.子查询没有用LIMIT或者外查询不是表的连接
9.子查询没有用LIMIT或者外查询没有用集函数
10.子查询没有用集函数或者外查询没用LIMIT
11.子查询和外查询不是同时是ORDER BY子句
12.子查询和外查询没有都用LIMIT
13.子查询没有用OFFSET
14.外查询不是一个复合查询的一部分或者子查询没有同时用关键字ORDER BY和LIMIT
15.外查询没有用集函数子查询不包含ORDER BY
16.复合子查询的扁平化:子查询不是一个复合查询,或者他是一个UNION ALL复合查询,但他是都由若干个非集函数的查询构成,他的父查询不是一个复合查询的子查询,也没有用集函数或者是DISTINCT查询,并且在FROM语句中没有其它的表或者子查询,父查询和子查询可能会包含WHERE语句,这些都会受到上面11、12、13条件的限制。
例: SELECT a+1 FROM (
SELECT x FROM tab
UNION ALL
SELECT y FROM tab
UNION ALL
SELECT abs(z*2) FROM tab2
) WHERE a!=5 ORDER BY 1
转换为:
SELECT x+1 FROM tab WHERE x+1!=5
UNION ALL
SELECT y+1 FROM tab WHERE y+1!=5
UNION ALL
SELECT abs(z*2)+1 FROM tab2 WHERE abs(z*2)+1!=5
ORDER BY 1
17.如果子查询是一个复合查询,那么父查询的所有的ORDER BY语句必须是对子查询的列的简单引用
18.子查询没有用LIMIT或者外查询不具有WHERE语句
子查询扁平化是由专门一个函数实现的,函数为:
static int flattenSubquery(
Parse *pParse, /* Parsing context */
Select *p, /* The parent or outer SELECT statement */
int iFrom, /* Index in p->pSrc->a[] of the inner subquery */
int isAgg, /* True if outer SELECT uses aggregate functions */
int subqueryIsAgg /* True if the subquery uses aggregate functions */
)
它是在Select.c文件中实现的。显然对于一个比较复杂的查询,如果满足上面的条件时对这个查询语句进行扁平化处理后就可以实现对查询的优化。如果正好存在索引的话效果会更好!
五、连接查询
在返回查询结果之前,相关表的每行必须都已经连接起来,在SQLite中,这是用嵌套循环实现的,在早期版本中,最左边的是最外层循环,最右边的是最内层循环,连接两个或者更多的表时,如果有索引则放到内层循环中,也就是放到FROM最后面,因为对于前面选中的每行,找后面与之对应的行时,如果有索引则会很快,如果没有则要遍历整个表,这样效率就很低,但在新版本中,这个优化已经实现。
优化的方法如下:
对要查询的每个表,统计这个表上的索引信息,首先将代价赋值为SQLITE_BIG_DBL(一个系统已经定义的常量):
1) 如果没有索引,则找有没有在这个表上对rowid的查询条件:
1.如果有Rowid=EXPR,如果有的话则返回对这个表代价估计,代价计为零,查询得到的记录数为1,并完成对这个表的代价估计,
2.如果没有Rowid=EXPR 但有rowid IN (...),而IN是一个列表,那么记录返回记录数为IN列表中元素的个数,估计代价为NlogN,
3.如果IN不是一个列表而是一个子查询结果,那么由于具体这个子查询不能确定,所以只能估计一个值,返回记录数为100,代价为200。
4.如果对rowid是范围的查询,那么就估计所有符合条件的记录是总记录的三分之一,总记录估计为1000000,并且估计代价也为记录数。
5.如果这个查询还要求排序,则再另外加上排序的代价NlogN
6.如果此时得到的代价小于总代价,那么就更新总代价,否则不更新。
2) 如果WHERE子句中存在OR操作符,那么要把这些OR连接的所有子句分开再进行分析。
1. 如果有子句是由AND连接符构成,那么再把由AND连接的子句再分别分析。
2. 如果连接的子句的形式是X<op><expr>,那么就再分析这个子句。
3. 接下来就是把整个对OR操作的总代价计算出来。
4. 如果这个查询要求排序,则再在上面总代价上再乘上排序代价NlogN
5. 如果此时得到的代价小于总代价,那么就更新总代价,否则不更新。
3) 如果有索引,则统计每个表的索引信息,对于每个索引:
1. 先找到这个索引对应的列号,再找到对应的能用到(操作符必须为=或者是IN(…))这个索引的WHERE子句,如果没有找到,则退出对每个索引的循环,如果找到,则判断这个子句的操作符是什么,如果是=,那么没有附加的代价,如果是IN(sub-select),那么估计它附加代价inMultiplier为25,如果是IN(list),那么附加代价就是N(N为list的列数)。
2. 再计算总的代价和总的查询结果记录数和代价。
3. nRow = pProbe->aiRowEst[i] * inMultiplier;/*计算行数*/
4. cost = nRow * estLog(inMultiplier);/*统计代价*/
5. 如果找不到操作符为=或者是IN(…)的子句,而是范围的查询,那么同样只好估计查询结果记录数为nRow/3,估计代价为cost/3。
6. 同样,如果此查询要求排序的话,再在上面的总代价上加上NlogN
7. 如果此时得到的代价小于总代价,那么就更新总代价,否则不更新。
4) 通过上面的优化过程,可以得到对一个表查询的总代价(就是上面各个代价的总和),再对第二个表进行同样的操作,这样如此直到把FROM子句中所有的表都计算出各自的代价,最后取最小的,这将作为嵌套循环的最内层,依次可以得到整个嵌套循环的嵌套顺序,此时正是最优的,达到了优化的目的。
5) 所以循环的嵌套顺序不一定是与FROM子句中的顺序一致,因为在执行过程中会用索引优化来重新排列顺序。
六、索引
在SQLite中,有以下几种索引:
1) 单列索引
2) 多列索引
3) 唯一性索引
4) 对于声明为:INTEGER PRIMARY KEY的主键来说,这列会按默认方式排序,所以虽然在数据字典中没有对它生成索引,但它的功能就像个索引。所以如果在这个主键上在单独建立索引的话,这样既浪费空间也没有任何好处。
运用索引的注意事项:
1) 对于一个很小的表来说没必要建立索引
2) 在一个表上如果经常做的是插入更新操作,那么就要节制使用索引
3) 也不要在一个表上建立太多的索引,如果建立太多的话那么在查询的时候SQLite可能不会选择最好的来执行查询,一个解决办法就是建立聚蔟索引
索引的运用时机:
1) 操作符:=、>、<、IN等
2) 操作符BETWEEN、LIKE、OR不能用索引,
如BETWEEN:SELECT * FROM mytable WHERE myfield BETWEEN 10 and 20;
这时就应该将其转换成:
SELECT * FROM mytable WHERE myfield >= 10 AND myfield <= 20;
此时如果在myfield上有索引的话就可以用了,大大提高速度
再如LIKE:SELECT * FROM mytable WHERE myfield LIKE 'sql%';
此时应该将它转换成:
SELECT * FROM mytable WHERE myfield >= 'sql' AND myfield < 'sqm';
此时如果在myfield上有索引的话就可以用了,大大提高速度
解释: 如果查询是LIKE 'sql%';,那么说明要查询的字符串格式是前三位必须是sql,后面可以是任意位任何字符,那么 myfield >= 'sql' 的意思就是说明要找的字符串要比'sql'长或者就是'sql',而后面的'sqm'的意思是说要找的字符串的第三个必须要比m小,再加上前面的限制条件,所以只能是'l'了,所以myfield >= 'sql' AND myfield < 'sqm'就找到了LIKE 'sql%'的字符串。
再如OR:SELECT * FROM mytable WHERE myfield = 'abc' OR myfield = 'xyz';
此时应该将它转换成:
SELECT * FROM mytable WHERE myfield IN ('abc', 'xyz');
此时如果在myfield上有索引的话就可以用了,大大提高速度
3) 有些时候索引都是不能用的,这时就应该遍历全表(程序演示)
SELECT * FROM mytable WHERE myfield % 2 = 1;
SELECT * FROM mytable WHERE substr(myfield, 0, 1) = 'w';
SELECT * FROM mytable WHERE length(myfield) < 5;
转自:http://www.cnblogs.com/hustssrs/archive/2009/03/03/1402078.html
SQLite的查询优化的更多相关文章
- SQLite查询优化性能要点
Sqlite是轻量级的,在编译之后很小,其中一个原因就是在查询优化方面比较简单,它只是运用索引机制来进行优化的,经过对SQLite的查询优化的分析以及对源代码的研究,我将SQLite的查询优总结如下: ...
- SQLite剖析之临时文件、内存数据库
一.7种临时文件 SQLite中,一个数据库由单个磁盘文件构成,简化了SQLite的使用,因为移动或备份数据库只要拷贝单个文件即可.这也使得SQLite适合用作应用程序文件格式.但是,当在单个文 ...
- SQLite3源程序分析之查询处理及优化
前言 查询处理及优化是关系数据库得以流行的根本原因,也是关系数据库系统最核心的技术之一.SQLite的查询处理模块很精致,而且很容易移植到不支持SQL的存储引擎(Berkeley DB最新的版本已经将 ...
- SQLite剖析之存储模型
前言 SQLite作为嵌入式数据库,通常针对的应用的数据量相对于DBMS的数据量小.所以它的存储模型设计得非常简单,总的来说,SQLite把一个数据文件分成若干大小相等的页面,然后以B树的形式来组织这 ...
- SQLite剖析之事务处理技术
前言 事务处理是DBMS中最关键的技术,对SQLite也一样,它涉及到并发控制,以及故障恢复等等.在数据库中使用事务可以保证数据的统一和完整性,同时也可以提高效率.假设需要在一张表内一次插入20个人的 ...
- SQLite剖析之内核研究
先从全局的角度把握SQLite内核各个模块的设计和功能.SQLite采用了层次化.模块化的设计,而这些使得它的可扩展性和可移植性非常强.而且SQLite的架构与通用DBMS的结构差别不是很大,所以它对 ...
- [Android新手区] SQLite 操作详解--SQL语法
该文章完全摘自转自:北大青鸟[Android新手区] SQLite 操作详解--SQL语法 :http://home.bdqn.cn/thread-49363-1-1.html SQLite库可以解 ...
- SQLite入门与分析(四)---Page Cache之事务处理(2)
写在前面:个人认为pager层是SQLite实现最为核心的模块,它具有四大功能:I/O,页面缓存,并发控制和日志恢复.而这些功能不仅是上层Btree的基础,而且对系统的性能和健壮性有关至关重要的影响. ...
- SQLite入门与分析(三)---内核概述(2)
写在前面:本节是前一节内容的后续部分,这两节都是从全局的角度SQLite内核各个模块的设计和功能.只有从全局上把握SQLite,才会更容易的理解SQLite的实现.SQLite采用了层次化,模块化的设 ...
随机推荐
- WSDL文档框架
- ehcache、memcache、redis三大缓存比较(转)
最近项目组有用到这三个缓存,去各自的官方看了下,觉得还真的各有千秋!今天特意归纳下各个缓存的优缺点,仅供参考! Ehcache 在Java项目广泛的使用.它是一个开源的.设计于提高在数据从RDBMS ...
- Swift语言之View,Button控件实现小方块在界面上的移动(纯代码实现)
import UIKit class ViewController: UIViewController { var diamonds:UIView! var diamondsXY = CGRectMa ...
- Machine-learning of Andrew Ng
Machine-learning of Andrew Ng 1.基础概念 机器学习是一门研究在非特定编程条件下让计算机采取行动的学科.最近二十年,机器学习为我们带来了自动驾驶汽车.实用的语音识别.高效 ...
- Android Studio查看android源码
Android Studio的默认版本在/Applications/Android Studio.app/Contents/info.plist中设置,默认没有1.8.如下: <key>J ...
- 更改jdk所用内存空间
在做项目是有时候会遇到内存jvm内存不够用的情况,在myeclipse是这样设置的. -Xms128m -Xmx512m -XX:PermSize=128m -XX:MaxPermSize=128m
- 【EasyUi】页面设计必学之Layout
接触EasyUi也快一年了.非常多时候都把重心放在实现功能方面.要显示大量数据了就用DataGrid,要实现分页效果了就想着Tabs,如此等等,再接下来就是考虑CSS.js怎样让这个功能实现的更好. ...
- 关于心理的二十五种倾向(查理·芒格)-3
9)回馈倾向人们早就发现.和猿类,猴类,狗类等其它很多认知能力较为低下的物种同样,人类身上也有以德报德,以牙还牙的极端倾向:这样的倾向明显能够促进有利于成员利益的团体合作.这跟非常多社会性的动物的基因 ...
- 无意中发现Markdown,最终解放了我
文件夹 概述 换行 删除线 链接自己主动识别 表格 代码块高亮 定义列表 脚注 自己主动生成文件夹 參考资料 正文 概述 大部分情况下,Markdown的基本的语法已够我们使用,比方随性记录点东西.非 ...
- swift 旋转加载动画
https://github.com/naoyashiga/RPLoadingAnimation