sql优化
Posted zqlmianshi
tags:
篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了sql优化相关的知识，希望对你有一定的参考价值。
1.建立索引
2.应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
3、应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num is null
可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：
select id from t where num=0
4、应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
select id from t where num=10 or num=20
可以这样查询：
select id from t where num=10
union all
select id from t where num=20
5、下面的查询也将导致全表扫描：
select id from t where name like ‘%abc%’
若要提高效率，可以考虑全文检索。
6、in 和 not in 也要慎用，否则会导致全表扫描，如：
select id from t where num in(1,2,3)
对于连续的数值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
7、如果在 where 子句中使用参数，也会导致全表扫描。因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。如下面语句将进行全表扫描：
select id from t where num=@num
可以改为强制查询使用索引：
select id from t with(index(索引名)) where num=@num
8、应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where num/2=100
应改为:
select id from t where num=100*2
9、应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
select id from t where substring(name,1,3)=‘abc’–name以abc开头的id
select id from t where datediff(day,createdate,‘2005-11-30’)=0–\'2005-11-30’生成的id
应改为:
select id from t where name like ‘abc%’
select id from t where createdate>=‘2005-11-30’ and createdate<‘2005-12-1’
10、不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
11、在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
12、不要写一些没有意义的查询，如需要生成一个空表结构：
select col1,col2 into #t from t where 1=0
这类代码不会返回任何结果集，但是会消耗系统资源的，应改成这样：
create table #t(…)
13、很多时候用 exists 代替 in 是一个好的选择：
select num from a where num in(select num from b)
用下面的语句替换：
select num from a where exists(select 1 from b where num=a.num)
14、并不是所有索引对查询都有效，SQL是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL查询可能不会去利用索引，如一表中有字段sex，male、female几乎各一半，那么即使在sex上建了索引也对查询效率起不了作用。
15、索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，因为 insert 或 update 时有可能会重建索引，所以怎样建索引需要慎重考虑，视具体情况而定。一个表的索引数最好不要超过6个，若太多则应考虑一些不常使用到的列上建的索引是否有必要。
16、应尽可能的避免更新 clustered 索引数据列，因为 clustered 索引数据列的顺序就是表记录的物理存储顺序，一旦该列值改变将导致整个表记录的顺序的调整，会耗费相当大的资源。若应用系统需要频繁更新 clustered 索引数据列，那么需要考虑是否应将该索引建为 clustered 索引。
17、尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。这是因为引擎在处理查询和连接时会逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
18、尽可能的使用char/nchar 代替 varchar/nvarchar ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
19、任何地方都不要使用 select * from t ，用具体的字段列表代替“*”，不要返回用不到的任何字段。
20、尽量使用表变量来代替临时表。如果表变量包含大量数据，请注意索引非常有限（只有主键索引）。
21、避免频繁创建和删除临时表，以减少系统表资源的消耗。
22、临时表并不是不可使用，适当地使用它们可以使某些例程更有效，例如，当需要重复引用大型表或常用表中的某个数据集时。但是，对于一次性事件，最好使用导出表。
23、在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
24、如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
25、尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
26、使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
27、与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。在结果集中包括“合计”的例程通常要比使用游标执行的速度快。如果开发时间允许，基于游标的方法和基于集的方法都可以尝试一下，看哪一种方法的效果更好。
28、在所有的存储过程和触发器的开始处设置 SET NOCOUNT ON ，在结束时设置 SET NOCOUNT OFF 。无需在执行存储过程和触发器的每个语句后向客户端发送 DONE_IN_PROC 消息。
29、尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。
30、尽量避免大事务操作，提高系统并发能力。
基于MySQL 的 SQL 优化总结
文章首发于我的个人博客，欢迎访问。https://blog.itzhouq.cn/mysql1
基于MySQL 的 SQL 优化总结
在数据库运维过程中，优化 SQL 是 DBA 团队的日常任务。例行 SQL 优化，不仅可以提高程序性能，还能减低线上故障的概率。
目前常用的 SQL 优化方式包括但不限于：业务层优化、SQL 逻辑优化、索引优化等。其中索引优化通常通过调整索引或新增索引从而达到 SQL 优化的目的。索引优化往往可以在短时间内产生非常巨大的效果。
--- 来自美团技术团队
SQL 优化是一个复杂的问题，不同版本和种类的数据库、不同数据级的数据需要选择不同的优化策略。
说明：我这里简单总结一下 SQL 优化，很多的大佬写过这方面的细节和用法，甚至还有相关的案例。我只是作为一个阶段性的总结，肯定是不全面的。如有错误和不当之处，欢迎批评指正，不胜感激。
从日常开发写 SQL 的角度看，需要遵循一些规则，但是这些规则只能解决部分问题。因为随着开发和数据量的增长，SQL 还是会变慢，这个时候需要一些针对性的措施，比如针对性地添加索引，通过命令或者工具分析变慢的 SQL 等等。
说说 SQL 优化的其中两个大的原则（肯定还有别的）：
原则一：尽量避免全表扫描。
原则二：通过索引优化。
这两个涉及的点比较多，他们之间也是有联系的，下面详细说说。
1、避免全表扫描
为啥要避免全表扫描呢？因为全表扫描耗费更多的时间。
那么从哪些方法避免全表扫描呢？
对 where 和 order by 涉及的列建立索引可以提高访问速度。但是要注意，并不是你建立了索引，索引就一定会生效。如果没有生效查询时还是全表扫描，速度还是得不到提升。那如何判断索引没有生效呢？可以借助 explain + SQL 语句的结果判断。大佬写的MySQL EXPLAIN 命令: 查看查询执行计划中总结了用法。简单的说，使用该命令分析的结果中很多字段，其中type 描述了查询的方式，如果 type 的结果是ALL，那么索引肯定没起作用。下面总结一下如何避免索引失效。
1、避免在 where 子句中对字段进行 null 判断
select id from user where name is null
2、避免在 where 子句使用 != 或者 <>
3、避免在 where 子句中对表达式进行操作
select id from user where age/2 = 20
修改为：
select id from user where age = 20 * 2
4、避免在 where 子句中对字段进行函数操作
5、避免在 like 查询中将 %放在开头
select id from user where username like ‘%wh‘
2、索引优化
适当地添加索引可以提高 SQL 的速度，但也有些注意点。
1、使用联合索引时，注意索引列的顺序，一般遵循最左匹配原则
比如一个索引：
KEY `idx_userid_age` (`userId`, `age`) USING BTREE
符合最左匹配原则的写法是把userid放在前面
select userid, name from user where userid = 1001 and age = 10
当我们创建的这个联合索引，就相当于创建了(userid)和(userid, age)两个索引。联合索引不满足最左原则，一般会失效，但是这个还跟 MySQL 优化器有关系。
2、在适当的时候，使用覆盖索引
通常在使用索引检索数据之后，需要访问磁盘上数据表文件读取所需要的列，这种操作成为“回表”。
若索引中包含查询的所有列，则不需要回表操作，直接从索引文件中读取数据即可，这种索引成为“覆盖索引”。
在查询时尽量减少select *，只查询需要的行，条件允许时尽量建立覆盖索引。
3、删除冗余索引
索引并不是越多越好，冗余的索引会影响性能。
比如，索引(A, B)相当于创建了索引(A)和索引(A, B)。
4、注意索引的数量
索引不是越多越好，一般不要超过 5 个。索引虽然提高了查询效率，但是也会降低插入和更新的效率。插入或更新可能会重建索引，索引建立索引也需要慎重考虑。
5、索引不适合建立在有大量重复的字段上，如性别这类字段
3、其他
其他原则包括但不限于：
1、查询 SQL 尽量不要使用 select *，而是 select 某字段。
2、连表查询的时候尽量将数据量少的表驱动数据多的表。
3、如果插入的数据较多时，考虑批量插入。
4、原则上不要有超过 5 张以上的表连接
阿里巴巴开发手册中规定超过三个表禁止 join的，但是这些规范的适用性还是要考虑环境。当连表数量较少时，连表路径算法选择的是动态规划算法；但是连表太多的情况下，路径算法可能退化成贪心算法，连表的方案可能不是最优的的。
这种情况下，如何写 SQL 呢？答案是通过可以通过冗余实现，细节就不展开了。
4、通过工具分析 SQL
说说几个用到的 SQL 分析工具
4.1 MySQL 自带的慢查询日志
MySQL 的慢查询日志是 MySQL 提供的一种日志，记录，用于记录在 MySQL 中响应时间超过设定的阈值的语句。在 MySQL 的配置文件 my.ini中开启后，支持将慢查询日志写入文件或者数据库。通过explain关键词模拟优化器执行 SQL，分析慢查询 SQL。
分析相关语句使用了哪些表、连接的类型、扫描的行数、使用的索引等。
4.2 日志分析工具 MySQLdumpslow
在生产环境中，手工分析日志、查找 SQL 比较费时间。MySQL 提供的 MySQLdumpslow 工具可以得到一些 SQL 访问的统计数据，比如访问次数最多的 10 条 SQL 等。
4.3 第三方工具：美团技术团队的 SQLAdvisor
由美团技术团队维护的一个开源的分析 SQL，给出索引优化建议的工具。
只是大概做了个总结，细节都没有展开，有兴趣的同学自行学习吧。
参考文章：
以上是关于sql优化的主要内容，如果未能解决你的问题，请参考以下文章