如果输入一条查询一张表的sql语句，但数据库执行缓慢，如何并采取什么样的方法对数据库进行优化

最有效的方法：创建索引！

如：select from 产品 where 产品ID='1234'

那么，在“产品ID”字段上如果创建的索引，则查询速度将会大大加快。

另外，

1、还可以通过Where条件，减少每次查询的数据量。

2、将查询语句放在存储过程中，因为存储过程中的语句在首次调用时会被编译，以后再次调用进直接执行编译过的程序。

SQLite是个典型的嵌入式DBMS，它有很多优点，它是轻量级的，在编译之后很小，其中一个原因就是在查询优化方面比较简单，它只是运用索引机制来进行优化的，经过对SQLite的查询优化的分析以及对源代码的研究，我将SQLite的查询优总结如下：

一、影响查询性能的因素：

1． 对表中行的检索数目，越小越好

2． 排序与否。

3． 是否要对一个索引。

4． 查询语句的形式

二、几个查询优化的转换

1． 对于单个表的单个列而言，如果都有形如TC=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(z2) 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(z2)+1 FROM tab2 WHERE abs(z2)+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 /

)

它是在Selectc文件中实现的。显然对于一个比较复杂的查询，如果满足上面的条件时对这个查询语句进行扁平化处理后就可以实现对查询的优化。如果正好存在索引的话效果会更好！

五、连接查询

在返回查询结果之前，相关表的每行必须都已经连接起来，在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上有索引的话就可以用了，大大提高速度

再如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;

目测题主写出的这几条语句未发现特别消耗系统资源的运算，都是一些规范的写法，可以说没有什么可以优化的，如果需要让它们运行的更快一些应该从设置索引这个方向去解决。

最前两条语句无筛选、用字段`houseid`排序运算，毫秒级耗时都非常快，该字段应该建立了索引并被利用。

语句1 用字段infocat=1进行筛选，尽管还是用字段`houseid`排序运算，但是耗时立即增加到数百毫秒级，显然字段`infocat`没有可被利用的索引。建议为字段infocat添加索引，这样相信此语句的运行速度会大幅提高。

语句2 用字段`edittime`排序，无筛选，耗时较用字段`houseid`排序的耗时从毫秒级大幅增加到3百多毫秒，显然字段`edittime`也无可利用的索引。如为此字段添加索引，此语句的运行速度可提高一个数量级。

语句3跟语句1情况一样，如果字段`infocat`有索引，其运行速度可大幅提高。如果筛选后返回的行特别多，那么再为字段`edittime`加索引可为提高运行速度加分（筛选后如返回的行数目有限，则字段`edittime`有无索引对提高速度帮助作用不大）。

1 SQL优化的原则是：将一次 *** 作需要读取的BLOCK数减到最低,即在最短的时间达到最大的数据吞吐量。 \r\n调整不良SQL通常可以从以下几点切入： \r\n 检查不良的SQL，考虑其写法是否还有可优化内容 \r\n 检查子查询 考虑SQL子查询是否可以用简单连接的方式进行重新书写 \r\n 检查优化索引的使用 \r\n 考虑数据库的优化器 \r\n\r\n2 避免出现SELECT FROM table 语句，要明确查出的字段。 \r\n\r\n3 在一个SQL语句中，如果一个where条件过滤的数据库记录越多，定位越准确，则该where条件越应该前移。 \r\n\r\n4 查询时尽可能使用索引覆盖。即对SELECT的字段建立复合索引，这样查询时只进行索引扫描，不读取数据块。 \r\n\r\n5 在判断有无符合条件的记录时建议不要用SELECT COUNT （）和select top 1 语句。 \r\n\r\n6 使用内层限定原则，在拼写SQL语句时，将查询条件分解、分类，并尽量在SQL语句的最里层进行限定，以减少数据的处理量。 \r\n\r\n7 应绝对避免在order by子句中使用表达式。 \r\n\r\n8 如果需要从关联表读数据，关联的表一般不要超过7个。 \r\n\r\n9 小心使用 IN 和 OR，需要注意In集合中的数据量。建议集合中的数据不超过200个。 \r\n\r\n10 用 代替，>用>=代替，1000)。应该用如下语句代替：select name from customer inner join order on customercustomer_id=ordercustomer_id where ordermoney>100。 \r\n\r\n15 在WHERE 子句中，避免对列的四则运算，特别是where 条件的左边，严禁使用运算与函数对列进行处理。比如有些地方 substring 可以用like代替。 \r\n\r\n16 如果在语句中有not in（in） *** 作，应考虑用not exists（exists）来重写,最好的办法是使用外连接实现。 \r\n\r\n17 对一个业务过程的处理，应该使事物的开始与结束之间的时间间隔越短越好，原则上做到数据库的读 *** 作在前面完成，数据库写 *** 作在后面完成，避免交叉。 \r\n\r\n18 请小心不要对过多的列使用列函数和order by,group by等，谨慎使用disti软件开发t。 \r\n\r\n19 用union all 代替 union，数据库执行union *** 作，首先先分别执行union两端的查询，将其放在临时表中，然后在对其进行排序，过滤重复的记录。 \r\n当已知的业务逻辑决定query A和query B中不会有重复记录时，应该用union all代替union，以提高查询效率。

1 tfax_number 和 tdtelephone 都应该有索引，不然怎么弄都慢的

2 换用存在语法代替in语法，楼上有说的

3 不觉得连接语法会比存在语法快很多，lz可以试一下。

4 试试以下变通会不会快一点

SELECT SUM(CNT) FROM (select (select count() as cnt from receivefax t where tfax_number = tdtelephone) AS CNT from tmp_duanxin_ljx_20100402 td );

我试了一下这样比存在语法要快一倍，连接语法和存在语法的速度差别不大

你是说TD表中可能有重复的吗？如果这样的话，我这个查询应该是没有压缩重复的，连接查询也没有压缩，存在和in查询都是忽略了TD中的重复的。至于t中的重复，都是肯定没有压缩的

查询优化是很复杂的，和具体的表的设计情况、表中数据的重复情况等等也有很大关系的，你自己用多种方法试一试吧，如果是oracle 在PL/SQL中执行完了，按F5进去可以看具体的执行情况，其它的一般也带查询分析器之类的，只有这样才能真正看出你的SQL语句的执行效率的

以上就是关于如果输入一条查询一张表的sql语句，但数据库执行缓慢，如何并采取什么样的方法对数据库进行优化全部的内容，包括:如果输入一条查询一张表的sql语句，但数据库执行缓慢，如何并采取什么样的方法对数据库进行优化、sqlite查询怎么优化、求sql 查询语句加where 和 ORDER BY 后耗时优化等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！