‘壹’ 大数据干货：sql优化方案精解十则
一、避免进行null判断
应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，这里最好不要给数据库留NULL，尽可能的使用 NOT NULL填充数据库。
备注、描述、评论之类的可以设置为 NULL，最好不要使用NULL。不要错误的认为NULL 不需要空间，如char(100) 型，在字段建立时，空间就固定了。不管是否插入值(NULL也包含在内)，都是占用 100个字符的空间的，如果是varchar这样的变长字段， null 不占用空间。可以在num上设置默认值0，确保表中num列没有null值。
二、不要使用select *
使用select *的话会增加解析的时间，另外也会把不需要的数据同时查询出来，从而延长数据传输时间，耗费精力。如text类型的字段，通常用来保存一些内容比较繁杂的东西，如果使用select *，则会把该字段也查询出来。
三、谨慎使用模糊查询
当模糊匹配以%开头时，该列索引将失效。若不以%开头，该列索引有效。
四、不要使用列号
使用列号的话，将会增加不必要的解析时间。
五、优先使用UNION ALL，避免使用UNION
因为UNION 会将各查询子集的记录做比较，故比起UNION ALL ，通常速度都会慢上许多。一般来说，如果使用UNION ALL能满足要求的话，务必使用UNION ALL。还有一种情况，如果业务上能够确保不会出现重复记录。
六、在where语句或者order by语句中避免对索引字段进行计算操作
当在索引列上进行操作之后，索引将会失效。正确做法应该是将值计算好再传入进来。
七、使用not exist代替not in
如果查询语句使用了not in 那么内外表都进行全表扫描，没有用到索引;而not extsts 的子查询依然能用到表上的索引。
八、exist和in的区别
in 是把外表和内表作hash 连接，而exists是对外表作loop循环，每次loop循环
再对内表进行查询。因此，in用到的是外表的索引， exists用到的是内表的索引。如果查询的两个表大小相当，那么用in和exists差别不大。如果两个表中一个较小，一个是大表，则子查询表大的用exists，子查询表小的用in。
九、避免在索引列上做如下操作
1.避免在索引列上使用IS NULL和IS NOT NULL。
2.避免在索引列上出现数据类型转换。(比如某字段是String类型，参数传入时是int类型)当在索引列上使用如上操作时，索引将会失效，造成全表扫描。
十、复杂操作可以考虑适当拆成几步
有时候会有通过一个SQL语句来实现复杂业务的例子出现，为了实现复杂的业务，嵌套多级子查询。造成SQL性能问题。对于这种情况可以考虑拆分SQL，通过多个SQL语句实现，或者把部分程序能完成的工作交给程序完成。
‘贰’ 怎样进行sql数据库的优化
1、数据库空间是个概述，在sqlserver里，使用语句 exec sp_spaceused 'TableName' 这个语句来查。
‘叁’ 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区别
‘肆’ 如何进行SQL性能优化
这里分享下mysql优化的几种方法。
1、首先在打开的软件中，需要分别为每一个表创建 InnoDB FILE的文件。
‘伍’ sql调优的几种方式
你好，
SQL优化的一些方法
1.对查询进行优化，应尽量避免全表扫描，首先应考虑在 where 及 order by 涉及的列上建立索引。
2.应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描。
3.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
4.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描。
5.in 和 not in 也要慎用，否则会导致全表扫描，
6.下面的查询也将导致全表扫描：
select id from t where name like '%abc%'
7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。
8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。
9.不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
10.在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
‘陆’ 如何进行SQL性能优化
SQL Server数据库查询速度慢的原因有很多，常见的有以下几种：
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是数据库设计的缺陷)
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创建计算列导致查询不优化。
4、内存不足
5、网络速度慢
6、查询出的数据量过大（可以采用多次查询，其他的方法降低数据量）
7、锁或者死锁(这也是查询慢最常见的问题，是程序设计的缺陷)
8、sp_lock,sp_who,活动的用户查看,原因是读写竞争资源。
9、返回了不必要的行和列
10、查询语句不好，没有优化
●可以通过以下方法来优化查询 :
1、把数据、日志、索引放到不同的I/O设备上，增加读取速度，以前可以将Tempdb应放在RAID0上，SQL2000不在支持。数据量（尺寸）越大，提高I/O越重要。
2、纵向、横向分割表，减少表的尺寸(sp_spaceuse)
3、升级硬件
4、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。注意填充因子要适当（最好是使用默认值0）。索引应该尽量小，使用字节数小的列建索引好（参照索引的创建）,不要对有限的几个值的字段建单一索引如性别字段。
5、提高网速。
6、扩大服务器的内存,Windows 2000和SQL server 2000能支持4-8G的内存。
配置虚拟内存：虚拟内存大小应基于计算机上并发运行的服务进行配置。运行 Microsoft SQL Server? 2000时，可考虑将虚拟内存大小设置为计算机中安装的物理内存的1.5倍。如果另外安装了全文检索功能，并打算运行Microsoft搜索服务以便执行全文索引和查询，可考虑：将虚拟内存大小配置为至少是计算机中安装的物理内存的3倍。将SQL Server max server memory服务器配置选项配置为物理内存的1.5倍（虚拟内存大小设置的一半）。
7、增加服务器CPU个数;但是必须 明白并行处理串行处理更需要资源例如内存。使用并行还是串行程是MSSQL自动评估选择的。单个任务分解成多个任务，就可以在处理器上运行。例如耽搁查询 的排序、连接、扫描和GROUP BY字句同时执行，SQL SERVER根据系统的负载情况决定最优的并行等级，复杂的需要消耗大量的CPU的查询最适合并行处理。但是更新操作UPDATE,INSERT， DELETE还不能并行处理。
8、如果是使用like进行查询的话，简单的使用index是不行的，但是全文索引，耗空间。 like ''a%'' 使用索引 like ''%a'' 不使用索引用 like ''%a%'' 查询时，查询耗时和字段值总长度成正比,所以不能用CHAR类型，而是VARCHAR。对于字段的值很长的建全文索引。
9、DB Server 和APPLication Server 分离；OLTP和OLAP分离
10、分布式分区视图可用于实现数据库服务器联合体。
联合体是一组分开管理的服务器，但它们相互协作分担系统的处理负荷。这种通过分区数据形成数据库服务器联合体的机制能够扩大一组服务器，以支持大型的多层 Web 站点的处理需要。有关更多信息，参见设计联合数据库服务器。（参照SQL帮助文件''分区视图''）
a、在实现分区视图之前，必须先水平分区表
b、 在创建成员表后，在每个成员服务器上定义一个分布式分区视图，并且每个视图具有相同的名称。这样，引用分布式分区视图名的查询可以在任何一个成员服务器上 运行。系统操作如同每个成员服务器上都有一个原始表的复本一样，但其实每个服务器上只有一个成员表和一个分布式分区视图。数据的位置对应用程序是透明的。
11、重建索引 DBCC REINDEX ,DBCC INDEXDEFRAG,收缩数据和日志 DBCC SHRINKDB,DBCC SHRINKFILE. 设置自动收缩日志.对于大的数据库不要设置数据库自动增长，它会降低服务器的性能。
在T-sql的写法上有很大的讲究，下面列出常见的要点：首先，DBMS处理查询计划的过程是这样的：
1、 查询语句的词法、语法检查
2、 将语句提交给DBMS的查询优化器
3、 优化器做代数优化和存取路径的优化
4、 由预编译模块生成查询规划
5、 然后在合适的时间提交给系统处理执行
6、 最后将执行结果返回给用户。
其次，看一下SQL SERVER的数据存放的结构：一个页面的大小为8K(8060)字节，8个页面为一个盘区，按照B树存放。
‘柒’ sql语句调优的主要方法
SQL语句调优，要看在什么数据库平台，数据库不同使用的调优方式也不同。
总体来说，一种是通过查询系统数据库，找出最消耗资源的SQL，然后进行调优。
在有一种就是对已有的SQL语句进行调优，通常是查看SQL执行计划，是否有使用到索引，查看SQL的消耗，根据具体情况进行调优。