优化复杂的sql

1. 复杂慢sql语句如何优化

很简单啊，优先索引，第二结构，第三算法。
索引最简单，如果是SQL server客户端或者toad可以提示有哪些需要进行优化的地方。
结构就是针对要查询的值，尽量集中到一个表，减少串表，函数查询，左链的表字段查询。
算法就是OR还是IN？串表时IN还是EXISTS ？oracle in 的限制。条件执行顺序等。
然后还有其他注意的，例如只查固定字段就不要 select * 只要注意以上步骤，千万级数据串10个秒也能1秒内显示出来。
有条件的话，当然是用归档数据进行查询，这样就不会占用业务数据IO了，最后一步就是“云计算”（解析有一百种，没有统一概念，我的意识其实就是归档过程中根据分组维度计算好，并根据日期放进相关的表，减少表粒度，只进行简单的select查询）

2. 优化SQL有什么方法

在数据库应用系统中编写可执行的SQL语句可以有多种方式实现，但哪一条是最佳方案却难以确定。为了解决这一问题，有必要对SQL实施优化。简单地说，SQL语句的优化就是将性能低下的SQL语句转换成达到同样目的的性能更好的SQL语句。

优化SQL语句的原因

数据库系统的生命周期可以分成: 设计、开发和成品三个阶段。在设计阶段进行优化的成本最低，收益最大。在成品阶段进行优化的成本最高，收益最小。如果将一个数据库系统比喻成一座楼房，在楼房建好后进行矫正往往成本很高而收效很小（甚至可能根本无法矫正），而在楼房设计、生产阶段控制好每块砖瓦的质量就能达到花费小而见效高的目的。

为了获得最大效益，人们常需要对数据库进行优化。数据库的优化通常可以通过对网络、硬件、操作系统、数据库参数和应用程序的优化来进行。根据统计，对网络、硬件、操作系统、数据库参数进行优化所获得的性能提升全部加起来只占数据库应用系统性能提升的40%左右，其余60%的系统性能提升全部来自对应用程序的优化。许多优化专家甚至认为对应用程序的优化可以得到80%的系统性能提升。因此可以肯定，通过优化应用程序来对数据库系统进行优化能获得更大的收益。

对应用程序的优化通常可分为两个方面: 源代码的优化和SQL语句的优化。由于涉及到对程序逻辑的改变，源代码的优化在时间成本和风险上代价很高(尤其是对正在使用中的系统进行优化) 。另一方面，源代码的优化对数据库系统性能的提升收效有限，因为应用程序对数据库的操作最终要表现为SQL语句对数据库的操作。

对SQL语句进行优化有以下一些直接原因：

1. SQL语句是对数据库(数据) 进行操作的惟一途径，应用程序的执行最终要归结为SQL语句的执行，SQL语句的效率对数据库系统的性能起到了决定性的作用。

2. SQL语句消耗了70%～90%的数据库资源。

3. SQL语句独立于程序设计逻辑，对SQL语句进行优化不会影响程序逻辑，相对于对程序源代码的优化，对SQL语句的优化在时间成本和风险上的代价都很低。

4. SQL语句可以有不同的写法，不同的写法在性能上的差异可能很大。

5. SQL语句易学，难精通。SQL语句的性能往往同实际运行系统的数据库结构、记录数量等有关，不存在普遍适用的规律来提升性能。

传统的优化方法

SQL程序人员在传统上采用手工重写来对SQL语句进行优化。这主要依靠DBA或资深程序员对SQL语句执行计划的分析，依靠经验，尝试重写SQL语句，然后对结果和性能进行比较以试图找到性能较佳的SQL语句。这种做法存在着以下不足：

1. 无法找出SQL语句的所有可能写法。很可能花费了大量的时间也无法找到性能较佳的SQL语句。即便找到了某个性能较佳的SQL语句也无法知道是否存在性能更好的写法。

2. 非常依赖于人的经验，经验的多寡往往决定了优化后SQL语句的性能。

3. 非常耗时间。重写-->校验正确性-->比较性能，这一循环过程需要大量的时间。

根据传统的SQL优化工具的功能，人们一般将优化工具分为以下三代产品：

第一代的SQL优化工具是执行计划分析工具。这类工具对输入的SQL语句从数据库提取执行计划，并解释执行计划中关键字的含义。

第二代的SQL优化工具只能提供增加索引的建议，它通过对输入的SQL语句的执行计划的分析来产生是否要增加索引的建议。这类工具存在着致命的缺点——只分析了一条SQL语句就得出增加某个索引的结论，根本不理会(实际上也无法评估到)增加的索引对整体数据库系统性能的影响。

第三代工具是利用人工智能实现自动SQL优化。

人工智能自动SQL优化

随着人工智能技术的发展和在数据库优化领域应用的深入，在20世纪90年代末优化技术取得了突破性的进展，出现了人工智能自动SQL优化。人工智能自动SQL优化的本质就是借助人工智能技术，自动对SQL语句进行重写，找到性能最好的等效SQL语句。LECCO SQL Expert就采用了这种人工智能技术，其SQL Expert支持Oracle、Sybase、MS SQL Server和IBM DB2数据库平台。其突出特点是自动优化SQL语句。除此以外，还可以以人工智能知识库“反馈式搜索引擎”来重写SQL语句，并找出所有等效的SQL语句及可能的执行计划，通过测试运行为应用程序和数据库自动找到性能最好的SQL语句，提供微秒级的计时; 能够优化Web应用程序和有大量用户的在线事务处理中运行时间很短的SQL语句; 能通过比较源SQL和待选SQL的不同之处，为开发人员提供“边做边学式训练”，迅速提高开发人员的SQL编程技能等等。

该工具针对数据库应用的开发和维护阶段提供了数个特别的模块：SQL语法优化器、PL/SQL集成化开发调试环境(IDE)、扫描器、数据库监视器等。其核心模块之一“SQL 语法优化器”的工作原理大致如下：输入一条源SQL语句，“人工智能反馈式搜索引擎”对输入的SQL语句结合检测到的数据库结构和索引进行重写，产生N条等效的SQL语句输出，产生的N条等效SQL语句再送入“人工智能反馈式搜索引擎”进行重写，直至无法产生新的输出或搜索限额满，接下来对输出的SQL语句进行过滤，选出具有不同执行计划的SQL语句(不同的执行计划意味着不同的执行效率)，最后，对得到的SQL语句进行批量测试，找出性能最好的SQL语句（参见下图）。

图 人工智能自动SQL优化示意图

LECCO SQL Expert不仅能够找到最佳的SQL语句，它所提供的“边做边学式训练”还能够教会开发人员和数据库管理员如何写出性能最好的SQL语句。LECCO SQL Expert的SQL语句自动优化功能使SQL的优化变得极其简单，只要能够写出SQL语句，它就能帮开发人员找到最好性能的写法。

小 结

SQL语句是数据库应用中一个非常关键的部分，它执行性能的高低直接影响着应用程序的运行效率。正因为如此，人们在SQL语句的优化上投入了很大的精力，出现了许多SQL语句优化工具。随着人工智能等相关技术的日益成熟, 肯定还会有更多更好的工具出现，这将会给开发人员提供更多的帮助。

3. 如何优化SQL语句

一、问题的提出
在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的SQL语句，提高系统的可用性。
在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种原则来删除索引，这有助于写出高性能的SQL语句。
二、SQL语句编写注意问题
下面就某些SQL语句的where子句编写中需要注意的问题作详细介绍。在这些where子句中，即使某些列存在索引，但是由于编写了劣质的SQL，系统在运行该SQL语句时也不能使用该索引，而同样使用全表扫描，这就造成了响应速度的极大降低。
1.
IS
NULL
与
IS
NOT
NULL
不能用null作索引，任何包含null值的列都将不会被包含在索引中。即使索引有多列这样的情况下，只要这些列中有一列含有null，该列就会从索引中排除。也就是说如果某列存在空值，即使对该列建索引也不会提高性能。
任何在where子句中使用is
null或is
not
null的语句优化器是不允许使用索引的。
2.
联接列
对于有联接的列，即使最后的联接值为一个静态值，优化器是不会使用索引的。我们一起来看一个例子，假定有一个职工表(employee)，对于一个职工的姓和名分成两列存放(FIRST_NAME和LAST_NAME)，现在要查询一个叫比尔.克林顿(Bill
Cliton)的职工。
下面是一个采用联接查询的SQL语句，
select
*
from
employss
where
first_name||''||last_name
='Beill
Cliton';
上面这条语句完全可以查询出是否有Bill
Cliton这个员工，但是这里需要注意，系统优化器对基于last_name创建的索引没有使用。
当采用下面这种SQL语句的编写，Oracle系统就可以采用基于last_name创建的索引。
***
where
first_name
='Beill'
and
last_name
='Cliton';
.
带通配符(%)的like语句
同样以上面的例子来看这种情况。目前的需求是这样的，要求在职工表中查询名字中包含cliton的人。可以采用如下的查询SQL语句:
select
*
from
employee
where
last_name
like
'%cliton%';
这里由于通配符(%)在搜寻词首出现，所以Oracle系统不使用last_name的索引。在很多情况下可能无法避免这种情况，但是一定要心中有底，通配符如此使用会降低查询速度。然而当通配符出现在字符串其他位置时，优化器就能利用索引。在下面的查询中索引得到了使用:
select
*
from
employee
where
last_name
like
'c%';
4.
Order
by语句
ORDER
BY语句决定了Oracle如何将返回的查询结果排序。Order
by语句对要排序的列没有什么特别的限制，也可以将函数加入列中(象联接或者附加等)。任何在Order
by语句的非索引项或者有计算表达式都将降低查询速度。
仔细检查order
by语句以找出非索引项或者表达式，它们会降低性能。解决这个问题的办法就是重写order
by语句以使用索引，也可以为所使用的列建立另外一个索引，同时应绝对避免在order
by子句中使用表达式。
5.
NOT
我们在查询时经常在where子句使用一些逻辑表达式，如大于、小于、等于以及不等于等等，也可以使用and(与)、or(或)以及not(非)。NOT可用来对任何逻辑运算符号取反。下面是一个NOT子句的例子:
...
where
not
(status
='VALID')
如果要使用NOT，则应在取反的短语前面加上括号，并在短语前面加上NOT运算符。NOT运算符包含在另外一个逻辑运算符中，这就是不等于(<>)运算符。换句话说，即使不在查询where子句中显式地加入NOT词，NOT仍在运算符中，见下例:
...
where
status
<>'INVALID';
对这个查询，可以改写为不使用NOT:
select
*
from
employee
where
salary<3000
or
salary>3000;
虽然这两种查询的结果一样，但是第二种查询方案会比第一种查询方案更快些。第二种查询允许Oracle对salary列使用索引，而第一种查询则不能使用索引。
虽然这两种查询的结果一样，但是第二种查询方案会比第一种查询方案更快些。第二种查询允许Oracle对salary列使用索引，而第一种查询则不能使用索引。

4. 如何进行SQL性能优化

这里分享下mysql优化的几种方法。

1、首先在打开的软件中，需要分别为每一个表创建 InnoDB FILE的文件。

5. SQL执行与优化

SQL优化

执行计划,表关联查询顺序,优化策略与思路

下面再向前走一些，容我根据自己的认识说一下查询执行的流程是怎样的：

1.连接

1.1客户端发起一条Query请求，监听客户端的‘连接管理模块’接收请求

1.2将请求转发到‘连接进/线程模块’

1.3调用‘用户模块’来进行授权检查

1.4通过检查后，‘连接进/线程模块’从‘线程连接池’中取出空闲的被缓存的连接线程和客户端请求对接，如果失败则创建一个新的连接请求

2.处理

2.1先查询缓存，检查Query语句是否完全匹配，接着再检查是否具有权限，都成功则直接取数据返回

2.2上一步有失败则转交给‘命令解析器’，经过词法分析，语法分析后生成解析树

2.3接下来是预处理阶段，处理解析器无法解决的语义，检查权限等，生成新的解析树

2.4再转交给对应的模块处理

2.5如果是SELECT查询还会经由‘查询优化器’做大量的优化，生成执行计划

2.6模块收到请求后，通过‘访问控制模块’检查所连接的用户是否有访问目标表和目标字段的权限

2.7有则调用‘表管理模块’，先是查看table cache中是否存在，有则直接对应的表和获取锁，否则重新打开表文件

2.8根据表的meta数据，获取表的存储引擎类型等信息，通过接口调用对应的存储引擎处理

2.9上述过程中产生数据变化的时候，若打开日志功能，则会记录到相应二进制日志文件中

3.结果

3.1Query请求完成后，将结果集返回给‘连接进/线程模块’

3.2返回的也可以是相应的状态标识，如成功或失败等

3.3‘连接进/线程模块’进行后续的清理工作，并继续等待请求或断开与客户端的连接

接下来再走一步，让我们看看一条SQL语句的前世今生。

首先看一下示例语句

示例语句

执行顺序

SQL解析

1. FROM

当涉及多个表的时候，左边表的输出会作为右边表的输入，之后会生成一个虚拟表VT1。

(1-J1)笛卡尔积

计算两个相关联表的笛卡尔积(CROSS JOIN) ，生成虚拟表VT1-J1。

两次全表扫描

哈希索引,查找复杂度都是 O(1) 。

2. WHERE

对VT1过程中生成的临时表进行过滤，满足WHERE子句的列被插入到VT2表中。

注意：

此时因为分组，不能使用聚合运算；也不能使用SELECT中创建的别名；

与ON的区别：

如果有外部列，ON针对过滤的是关联表，主表（保留表）会返回所有的列；

如果没有添加外部列，两者的效果是一样的；

应用：

对主表的过滤应该放在WHERE；

对于关联表，先条件查询后连接则用ON，先连接后条件查询则用WHERE；

hash join 哈希连接 驱动表和被驱动表都只会访问0次或1次

应用场景:一个大表一个小表/表上没有索引/返回结果集比较大

3. GROUP BY

这个子句会把VT2中生成的表按照GROUP BY中的列进行分组。生成VT3表。

注意：

其后处理过程的语句，如SELECT,HAVING，所用到的列必须包含在GROUP BY中，对于没有出现的，得用聚合函数；

原因：

GROUP BY改变了对表的引用，将其转换为新的引用方式，能够对其进行下一级逻辑操作的列会减少；

原作者的理解是：

根据分组字段，将具有相同分组字段的记录归并成一条记录，因为每一个分组只能返回一条记录，除非是被过滤掉了，而不在分组字段里面的字段可能会有多个值，多个值是无法放进一条记录的，所以必须通过聚合函数将这些具有多值的列转换成单值；

GROUP BY 重新聚合查询

4. HAVING

这个子句对VT3表中的不同的组进行过滤，只作用于分组后的数据，满足HAVING条件的子句被加入到VT4表中。

7.LIMIT

LIMIT子句从上一步得到的VT6虚拟表中选出从指定位置开始的指定行数据。

注意：

offset和rows的正负带来的影响；

当偏移量很大时效率是很低的，可以这么做：

采用子查询的方式优化，在子查询里先从索引获取到最大id，然后倒序排，再取N行结果集

采用INNER JOIN优化，JOIN子句里也优先从索引获取ID列表，然后直接关联查询获得最终结果

当前未用到索引,

三次full scan , table1 AS a / table2 AS b / GROUP BY

尽量少做重复的工作

控制同一语句的多次执/减少多次的数据转换/

杜绝不必要的子查询和连接表，子查询在执行计划一般解释成外连接，多余的连接表带来额外的开销

关于临时表和表变量的选择

临时表产生使用SELECT INTO和CREATE TABLE + INSERT INTO的选择，一般情况下，SELECT INTO会比CREATE TABLE + INSERT INTO的方法快很多，但是SELECT INTO会锁定TEMPDB的系统表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用户并发环境下，容易阻塞其他进程，所以建议，在并发系统中，尽量使用CREATE TABLE + INSERT INTO，而大数据量的单个语句使用中，使用SELECT INTO。

子查询的用法

相关子查询可以用IN、NOT IN、EXISTS、NOT EXISTS引入

NOT IN、NOT EXISTS的相关子查询可以改用LEFT JOIN代替写法

如果保证子查询没有重复 ，IN、EXISTS的相关子查询可以用INNER JOIN 代替

IN``的相关子查询用EXISTS代替

不要用 COUNT (*)的子查询判断是否存在记录，最好用 LEFT` `JOIN 或者EXISTS，比如有人写这样的语句：

建立索引后，并不是每个查询都会使用索引，在使用索引的情况下，索引的使用效率也会有很大的差别。只要我们在查询语句中没有强制指定索引，

不要对索引字段进行运算，而要想办法做变换

不要对索引字段进行格式转换

不要对索引字段使用函数

不要对索引字段进行多字段连接

join关联查询的计算是很复杂的，特别是数据量比较大的情况下，实际情况还是拆解较快的

Join拆解的核心就是利用In关键字

要么用空间换时间，要么用时间换空间

多表连接的连接条件对索引的选择有着重要的意义，所以我们在写连接条件条件的时候需要特别注意。

A、多表连接的时候，连接条件必须写全，宁可重复，不要缺漏。

B、连接条件尽量使用聚集索引

C、注意ON、WHERE和HAVING部分条件的区别

ON是最先执行， WHERE次之，HAVING最后，因为ON是先把不符合条件的记录过滤后才进行统计，它就可以减少中间运算要处理的数据，按理说应该速度是最快的，WHERE也应该比 HAVING快点的，因为它过滤数据后才进行SUM，在两个表联接时才用ON的，所以在一个表的时候，就剩下WHERE跟HAVING比较了

考虑联接优先顺序：

(1)INNER JOIN

(2)LEFT JOIN (注：RIGHT JOIN 用 LEFT JOIN 替代)

(3)CROSS JOIN

索引并不适用于所有情况：a.少量数据；b.频繁进行改动的字段，不适合做索引；c.很少使用的字段，不需要加索引

索引会提高数据查询效率，但是会降低“增、删、改”的效率。当不使用索引的时候，我们进行数据的增删改，只需要操作源表即可，但是当我们添加索引后，不仅需要修改源表，也需要再次修改索引，很麻烦。

先执行顺序, 是否走索引, 有无类型转换

18000 字的SQL优化大全

步步深入：MySQL架构总览->查询执行流程->SQL解析顺序

MySQL索引总结（4）——btree与hash区别