MySQL性能调优【一】

目录

• 前言
• 使用explain 分析你SQL的计划
• 关键字的慎用
• • 避免判断 null 值
  • 避免使用 or 逻辑
  • 慎用 in 和 not in 逻辑
  • Inner join 、left join、right join，优先使用Inner join，若是是left join，左边表结果尽可能小
  • exists的合理使用
  • 慎用distinct关键字
  • 尽可能用 union all 替换 union
• 查询优化
• • GROUP BY关键字优化
  • 查询SQL尽可能不要使用select *，而是select具体字段
  • 优化limit分页
  • 知道查询结果为一条记录，建议使用limit 1
  • 注意模糊查询
  • 避免查询条件中字段计算
  • 避免查询条件中对字段进行函数操做
  • 避免不等值判断
  • 对查询进行优化，应考虑在 where 及 order by 涉及的列上创建索引，尽可能避免全表扫描。
  • where子句中考虑使用默认值代替null。
  • where子句 “= ” 左边注意点
  • 不要定义无心义的查询
• 索引优化
• • 在适当的时候，使用覆盖索引。
  • 索引无关优化
  • 索引也可能失效
  • 组合索引使用
  • 索引优化总结
• 其它注意事项
• • 表格字段类型选择
  • 若是插入数据过多，考虑批量插入
• count(*) 和 count(1)和count(列名)区别

前言

sql语句性能达不到你的要求，执行效率让你忍无可忍，通常会时下面几种状况。

• 网速不给力，不稳定。
• 服务器内存不够，或者SQL 被分配的内存不够。
• sql语句设计不合理
• 没有相应的索引，索引不合理
• 没有有效的索引视图
• 表数据过大没有有效的分区设计
• 数据库设计太差，存在大量的数据冗余
• 索引列上缺乏相应的统计信息，或者统计信息过时
• …

本片文章主要介绍的是如何sql优化方法跟技巧。

使用explain 分析你SQL的计划

平常开发写SQL的时候建议用explain分析一下本身书写的SQL语句，尤为是走不走索引这一块。使用 Explain 关键字能够模拟优化器执行SQL查询语句，从而知道 MySQL 是如何处理你的 SQL 语句的。分析你的查询语句或是表结构的性能瓶颈。

（1）语法：Explain + SQL语句
（2）执行计划包含的信息（若是有分区表的话还会有partitions）

• id（select 查询的序列号，包含一组数字，表示查询中执行select子句或操做表的顺序）。

  • id相同，执行顺序从上往下
  • id全不一样，若是是子查询，id的序号会递增，id值越大优先级越高，越先被执行
  • id部分相同，执行顺序是先按照数字大的先执行，而后数字相同的按照从上往下的顺序执行

• select_type（查询类型，用于区别普通查询、联合查询、子查询等复杂查询）

  • SIMPLE ：简单的select查询，查询中不包含子查询或UNION
  • PRIMARY：查询中若包含任何复杂的子部分，最外层查询被标记为PRIMARY
  • SUBQUERY：在select或where列表中包含了子查询
  • DERIVED：在from列表中包含的子查询被标记为DERIVED，MySQL会递归执行这些子查询，把结果放在临时表里
  • UNION：若第二个select出如今UNION以后，则被标记为UNION，若UNION包含在from子句的子查询中，外层 select将被标记为DERIVED
  • UNION RESULT：从UNION表获取结果的select

• table（显示这一行的数据是关于哪张表的）

• type（显示查询使用了那种类型，从最好到最差依次排列 system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL ）

  • system：表只有一行记录（等于系统表），是 const 类型的特例，平时不会出现
  • const：表示经过索引一次就找到了，const 用于比较 primary key 或 unique 索引，由于只要匹配一行数据，因此很快，如将主键置于 where 列表中，mysql 就能将该查询转换为一个常量
  • eq_ref：惟一性索引扫描，对于每一个索引键，表中只有一条记录与之匹配，常见于主键或惟一索引扫描
  • ref：非惟一性索引扫描，范围匹配某个单独值得全部行。本质上也是一种索引访问，他返回全部匹配某个单独值的行，然而，它可能也会找到多个符合条件的行，多以他应该属于查找和扫描的混合体
  • range：只检索给定范围的行，使用一个索引来选择行。key列显示使用了哪一个索引，通常就是在你的where语句中出现了between、<、>、in等的查询，这种范围扫描索引比全表扫描要好，由于它只需开始于索引的某一点，而结束于另外一点，不用扫描所有索引
  • index：Full Index Scan，index于ALL区别为index类型只遍历索引树。一般比ALL快，由于索引文件一般比数据文件小。（也就是说虽然all和index都是读全表，但index是从索引中读取的，而all是从硬盘中读的）
  • ALL：Full Table Scan，将遍历全表找到匹配的行

通常来讲，得保证查询至少达到range级别，最好到达ref

• possible_keys（显示可能应用在这张表中的索引，一个或多个，查询涉及到的字段若存在索引，则该索引将被列出，但不必定被查询实际使用）

• key

  • 实际使用的索引，若是为NULL，则没有使用索引

  • 查询中若使用了覆盖索引，则该索引和查询的 select 字段重叠，仅出如今key列表中

• key_len

  • 表示索引中使用的字节数，可经过该列计算查询中使用的索引的长度。在不损失精确性的状况下，长度越短越好
  • key_len显示的值为索引字段的最大可能长度，并不是实际使用长度，即key_len是根据表定义计算而得，不是经过表内检索出的

• ref（显示索引的哪一列被使用了，若是可能的话，是一个常数。哪些列或常量被用于查找索引列上的值）

• rows（根据表统计信息及索引选用状况，大体估算找到所需的记录所须要读取的行数）

• Extra（包含不适合在其余列中显示但十分重要的额外信息）

  • using filesort: 说明mysql会对数据使用一个外部的索引排序，不是按照表内的索引顺序进行读取。mysql中没法利用索引完成的排序操做称为“文件排序”。常见于order by和group by语句中

  • Using temporary：使用了临时表保存中间结果，mysql在对查询结果排序时使用临时表。常见于排序order by和分组查询group by。

  • using index：表示相应的select操做中使用了覆盖索引，避免访问了表的数据行，效率不错，若是同时出现using where，代表索引被用来执行索引键值的查找；不然索引被用来读取数据而非执行查找操做

  • using where：使用了where过滤

  • using join buffer：使用了链接缓存

  • impossible where：where子句的值老是false，不能用来获取任何元祖

  • select tables optimized away：在没有group by子句的状况下，基于索引优化操做或对于MyISAM存储引擎优化COUNT(*)操做，没必要等到执行阶段再进行计算，查询执行计划生成的阶段即完成优化

  • distinct：优化distinct操做，在找到第一匹配的元祖后即中止找一样值的动做

举例子：

• 第一行（执行顺序4）：id列为1，表示是union里的第一个select，select_type列的primary表示该查询为外层查询，table列被标记为，表示查询结果来自一个衍生表，其中derived3中3表明该查询衍生自第三个select查询，即id为3的select。【select d1.name…】

• 第二行（执行顺序2）：id为3，是整个查询中第三个select的一部分。因查询包含在from中，因此为derived。【select id,name from t1 where other_column=’’】

• 第三行（执行顺序3）：select列表中的子查询select_type为subquery，为整个查询中的第二个select。【select id from t3】

• 第四行（执行顺序1）：select_type为union，说明第四个select是union里的第二个select，最早执行【select name,id from t2】

• 第五行（执行顺序5）：表明从union的临时表中读取行的阶段，table列的<union1,4>表示用第一个和第四个select的结果进行union操做。【两个结果union操做】

关键字的慎用

避免判断 null 值

应尽可能避免在 where 子句中对字段进行 null 值判断，不然将致使引擎放弃使用索引从而进行全表扫描，如：select id from t where num is null
能够在 num 上设置默认值 0，确保表中 num 列没有 null 值，而后这样查询：
select id from t where num=0

避免使用 or 逻辑

应尽可能避免在 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

mysql是有优化器的，处于效率与成本考虑，遇到or条件，索引可能失效，看起来也合情合理。

慎用 in 和 not in 逻辑

in和 not in也要慎用，不然会致使全表扫描，如：

select id from t1 where num in(select id from t2 where id > 10)

此时外层查询会全表扫描，不使用索引。能够修改成：

select id from t1,(select id from t1 where id > 10)t2 where t1.id = t2.id

此时索引被使用，能够明显提高查询效率。

Inner join 、left join、right join，优先使用Inner join，若是是left join，左边表结果尽可能小

• Inner join 内链接，在两张表进行链接查询时，只保留两张表中彻底匹配的结果集
• left join在两张表进行链接查询时，会返回左表全部的行，即便在右表中没有匹配的记录。
• right join在两张表进行链接查询时，会返回右表全部的行，即便在左表中没有匹配的记录。

都知足SQL需求的前提下，推荐优先使用Inner join（内链接），若是要使用left join，左边表数据结果尽可能小，若是有条件的尽可能放到左边处理。

缘由：

• 若是inner join是等值链接，或许返回的行数比较少，因此性能相对会好一点。
• 同理，使用了左链接，左边表数据结果尽可能小，条件尽可能放到左边处理，意味着返回的行数可能比较少。

exists的合理使用

不少时候用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)

慎用distinct关键字

distinct关键字通常用来过滤重复记录，以返回不重复的记录。在查询一个字段或者不多字段的状况下使用时，给查询带来优化效果。可是在字段不少的时候使用，却会大大下降查询效率。

• 反例：
  SELECT DISTINCT * from user;
  

• 正例：
  select DISTINCT name from user;
  

• 理由：
  带distinct的语句cpu时间和占用时间都高于不带distinct的语句。由于当查询不少字段时，若是使用distinct，数据库引擎就会对数据进行比较，过滤掉重复数据，然而这个比较，过滤的过程会占用系统资源，cpu时间。
  

尽可能用 union all 替换 union

若是检索结果中不会有重复的记录，推荐union all 替换 union。

理由：若是使用union，无论检索结果有没有重复，都会尝试进行合并，而后在输出最终结果前进行排序。若是已知检索结果没有重复记录，使用union all 代替union，这样会提升效率。

查询优化

GROUP BY关键字优化

• group by实质是先排序后进行分组，遵守索引建的最佳左前缀
• 当没法使用索引列，增大max_length_for_sort_data 参数的设置，增大sort_buffer_size参数的设置
• where高于having，能写在where限定的条件就不要去having限定了

查询SQL尽可能不要使用select *，而是select具体字段

任何地方都不要使用 select * from t，用具体的字段列表代替“*”，不要返回用不到的任何字段。
优势：

• 只取须要的字段，节省资源、减小网络开销。
• select *进行查询时，极可能就不会使用到覆盖索引了，就会形成回表查询。

优化limit分页

咱们平常作分页需求时，通常会用 limit 实现，可是当偏移量特别大的时候，查询效率就变得低下。
所以咱们有如下优化方案：

• 返回上次查询的最大记录(偏移量)
  当偏移量最大的时候，查询效率就会越低，由于Mysql并不是是跳过偏移量直接去取后面的数据，而是先把偏移量+要取的条数，而后再把前面偏移量这一段的数据抛弃掉再返回的，返回上次最大查询记录（偏移量），这样能够跳过偏移量，效率提高很多。
  

• 使用order by + 索引
  使用order by+索引，也是能够提升查询效率的。
  

• 在业务容许的状况下限制页数
  建议跟业务讨论，有没有必要查这么后的分页啦。由于绝大多数用户都不会日后翻太多页。
  

知道查询结果为一条记录，建议使用limit 1

• 若是知道查询结果只有一条或者只要最大/最小一条记录，建议用limit 1，当加上limit 1后，只要找到了对应的一条记录,就不会继续向下扫描了,效率将会大大提升。
• 固然，若是name是惟一索引的话，是没必要要加上limit 1了，由于limit的存在主要就是为了防止全表扫描，从而提升性能,若是一个语句自己能够预知不用全表扫描，有没有limit ，性能的差异并不大。

注意模糊查询

若是用到模糊关键字查询，很容易想到like，可是like极可能让你的索引失效从而致使全表扫描，以下所示：

select id from t where name like '%abc%'

模糊查询若是是必要条件时，可使用 select id from t where name like 'abc%'来实现模糊查询，此时索引将被使用。若是头匹配是必要逻辑，建议使用全文搜索引擎（Elasticsearch、Lucene、Solr 等）。

• 把%放前面，并不走索引，把% 放关键字后面，仍是会走索引的。

避免查询条件中字段计算

应尽可能避免在 where 子句中对字段进行表达式操做，这将致使引擎放弃使用索引而进行全表扫描。如：

select id from t where num/2=100

应改成:

select id from t where num=100*2

避免查询条件中对字段进行函数操做

应尽可能避免在 where 子句中对字段进行函数操做，这将致使引擎放弃使用索引而进行全表扫描。
如：

select id from t where substring(name,1,3)='abc'  --name 以 abc 开头的 id

应改成:

select id from t where name like 'abc%'

缘由：须要什么数据，就去查什么数据，避免返回没必要要的数据，节省开销

避免不等值判断

应尽可能避免在 where 子句中使用!=或<>操做符，不然将引擎放弃使用索引而进行全表扫描。
例如：

select age,name  from user where age !=18;

以上使用!=或者<>极可能会致使索引失效从而进行全表扫描，因此咱们应该使用下面的方式：

//能够考虑分开两条sql写
select age,name  from user where age <18;
select age,name  from user where age >18;

对查询进行优化，应考虑在 where 及 order by 涉及的列上创建索引，尽可能避免全表扫描。

where子句中考虑使用默认值代替null。

• 并非说使用了is null或者is not null就会不走索引了，这个跟mysql版本以及查询成本都有关。
• 若是把null值，换成默认值，不少时候让走索引成为可能，同时，表达意思会相对清晰一点。

where子句 “= ” 左边注意点

不要在where 子句中的“=”左边进行函数、算术运算或其余表达式运算，不然系统将可能没法正确使用索引。

不要定义无心义的查询

不要写一些没有意义的查询，如须要生成一个空表结构：

select col1,col2 into #t from t where 1=0

这类代码不会返回任何结果集，可是会消耗系统资源的，应改为这样：

create table #t(...)

索引优化

在适当的时候，使用覆盖索引。

覆盖索引可以使得你的SQL语句不须要回表，仅仅访问索引就可以获得全部须要的数据，大大提升了查询效率。

索引无关优化

• 不使用*、尽可能不使用 union，union all等关键字、尽可能不使用 or关键字、尽可能使用等值判断。

• 表链接建议不超过 5 个。若是超过 5 个，则考虑表格的设计。（互联网应用中）

• 表链接方式使用外联优于内联。

• 外链接有基础数据存在。如：A left join B,基础数据是 A。

• A inner join B，没有基础数据的，先使用笛卡尔积完成全链接，在根据链接条件获得内链接结果集。

• 大数据量级的表格作分页查询时，若是页码数量过大，则使用子查询配合完成分页逻辑。

Select * from table limit 1000000, 10
Select * from table where id in (select pk from table limit 100000, 10)

索引也可能失效

并非全部索引对查询都有效，SQL 是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL 查询可能不会去利用索引，如一表中有字段 sex，male、female 几乎各一半，那么即便在 sex 上建了索引也对查询效率起不了做用。

组合索引使用

在使用索引字段做为条件时，若是该索引是复合索引，那么必须使用到该索引中的第一个字段做为条件时才能保证系统使用该索引，不然该索引将不会被使用，而且应尽量的让字段顺序与索引顺序相一致。

索引优化总结

• 全值匹配牛逼
• 最佳左前缀法则，好比创建了一个联合索引(a,b,c)，那么其实咱们可利用的索引就有(a), (a,b), (a,b,c)
• 不在索引列上作任何操做（计算、函数、(自动or手动)类型转换），会致使索引失效而转向全表扫描
• 存储引擎不能使用索引中范围条件右边的列
• 尽可能使用覆盖索引(只访问索引的查询(索引列和查询列一致))，减小select
• is null ,is not null 也没法使用索引
• like “xxxx%” 是能够用到索引的，like “%xxxx” 则不行(like “%xxx%” 同理)。like以通配符开头(’%abc…’)索引失效会变成全表扫描的操做，
• 字符串不加单引号索引失效
• 少用or，用它来链接时会索引失效
• <，<=，=，>，>=，BETWEEN，IN 可用到索引，<>，not in ，!= 则不行，会致使全表扫描

其它注意事项

表格字段类型选择

尽可能使用数字型字段，若只含数值信息的字段尽可能不要设计为字符型，这会下降查询和链接的性能，并会增长存储开销。这是由于引擎在处理查询和链接时会逐个比较字符串中每个字符，而对于数字型而言只须要比较一次就够了。

尽量的使用 varchar 代替char，由于首先可变长度字段存储空间小，能够节省存储空间，其次对于查询来讲，在一个相对较小的字段内搜索效率显然要高些。

若是插入数据过多，考虑批量插入

当咱们插入数据过多时，一次性插入会严重影响性能，同时会形成卡顿，浪费时间，所以建议分批次插入数据。
反例：

for(User u :list){
 INSERT into user(name,age) values(#name#,#age#) 
}

正例：

//一次500批量插入，分批进行
insert into user(name,age) values
<foreach collection="list" item="item" index="index" separator=",">
    (#{item.name},#{item.age})
</foreach>

count(*) 和 count(1)和count(列名)区别

从执行效果上：

• count(*)包括了全部的列，至关于行数，在统计结果的时候，不会忽略列值为NULL
• count(1)包括了全部列，用1表明代码行，在统计结果的时候，不会忽略列值为NULL
• count(列名)只包括列名那一列，在统计结果的时候，会忽略列值为空（这里的空不是只空字符串或者0，而是表示null）的计数，即某个字段值为NULL时，不统计。

执行效率上：

• 列名为主键，count(列名)会比count(1)快
• 列名不为主键，count(1)会比count(列名)快
• 若是表多个列而且没有主键，则 count(1) 的执行效率优于 count(*)
• 若是有主键，则select count（主键）的执行效率是最优的
• 若是表只有一个字段，则select count(*)最优。

有一个问题常常问：count(*)会形成全表扫描吗？

你们能够看如下这篇文章：【https://zhuanlan.zhihu.com/p/149874583?from_voters_page=true】
说明得很细。

参考： https://juejin.im/post/6850037271233331208#heading-65 https://www.jianshu.com/p/074f3eafcadf