MySQL索引优化铁则送你！！！|掘金技术征文-双节特别篇

时间  2021-08-12
标签 mysql sql 数据库 性能优化 markdown 数据库设计 函数 post 性能 优化 栏目 MySQL 繁體版
原文   原文链接

前言

  • 索引的相信你们都据说过，可是真正会用的又有几人？平时工做中写SQL真的会考虑到这条SQL如何可以用上索引，如何可以提高执行效率？
  • 此篇文章详细的讲述了索引优化的几个原则，只要在工做中可以随时应用到，相信你写出的SQL必定是效率最高，最牛逼的。
  • 文章的脑图以下：

索引优化几大规则

索引优化规则

一、like语句的前导模糊查询不能使用索引

select * from doc where title like '%XX'；   --不能使用索引
select * from doc where title like 'XX%'；   --非前导模糊查询，可使用索引
复制代码
  • 由于页面搜索严禁左模糊或者全模糊，若是须要可使用搜索引擎来解决。

二、union、in、or 都可以命中索引，建议使用 in

  1. union可以命中索引，而且MySQL 耗费的 CPU 最少。
select * from doc where status=1
union all
select * from doc where status=2;
复制代码
  1. in可以命中索引，查询优化耗费的 CPU 比 union all 多，但能够忽略不计，通常状况下建议使用 in。
select * from doc where status in (1, 2);
复制代码
  1. or 新版的 MySQL 可以命中索引，查询优化耗费的 CPU 比 in多，不建议频繁用or。
select * from doc where status = 1 or status = 2
复制代码
  1. 补充：有些地方说在where条件中使用or，索引会失效，形成全表扫描，这是个误区：

  • ①要求where子句使用的全部字段，都必须创建索引；mysql

  • ②若是数据量太少，mysql制定执行计划时发现全表扫描比索引查找更快，因此会不使用索引；sql

  • ③确保mysql版本5.0以上，且查询优化器开启了index_merge_union=on, 也就是变量optimizer_switch里存在index_merge_union且为on。数据库

三、负向条件查询不能使用索引

  • 负向条件有：!=、<>、not in、not exists、not like 等。性能优化

  • 例以下面SQL语句：markdown

select * from doc where status != 1 and status != 2;
复制代码
  • 能够优化为 in 查询：
select * from doc where status in (0,3,4);
复制代码

四、联合索引最左前缀原则

  • 若是在(a,b,c)三个字段上创建联合索引，那么他会自动创建 a| (a,b) | (a,b,c)组索引。数据库设计

  • 登陆业务需求，SQL语句以下：函数

select uid, login_time from user where login_name=? andpasswd=?
复制代码
  • 能够创建(login_name, passwd)的联合索引。由于业务上几乎没有passwd 的单条件查询需求，而有不少login_name 的单条件查询需求，因此能够创建(login_name, passwd)的联合索引，而不是(passwd, login_name)。
  1. 创建联合索引的时候，区分度最高的字段在最左边
  1. 存在非等号和等号混合判断条件时，在创建索引时，把等号条件的列前置。如 where a>? and b=?，那么即便a 的区分度更高，也必须把 b 放在索引的最前列。
  1. 最左前缀查询时，并非指SQL语句的where顺序要和联合索引一致。
  • 下面的 SQL 语句也能够命中 (login_name, passwd) 这个联合索引：
select uid, login_time from user where passwd=? andlogin_name=?
复制代码
  • 但仍是建议 where 后的顺序和联合索引一致，养成好习惯。
  1. 假如index(a,b,c), where a=3 and b like 'abc%' and c=4，a能用，b能用，c不能用。

五、不能使用索引中范围条件右边的列（范围列能够用到索引），范围列以后列的索引全失效

  • 范围条件有：<、<=、>、>=、between等。
  • 索引最多用于一个范围列，若是查询条件中有两个范围列则没法全用到索引。
  • 假若有联合索引 (empno、title、fromdate)，那么下面的 SQL 中 emp_no 能够用到索引，而title 和 from_date 则使用不到索引。
select * from employees.titles where emp_no < 10010' and title='Senior Engineer'and from_date between '1986-01-01' and '1986-12-31' 复制代码

六、不要在索引列上面作任何操做（计算、函数），不然会致使索引失效而转向全表扫描

  • 例以下面的 SQL 语句，即便 date 上创建了索引，也会全表扫描：
select * from doc where YEAR(create_time) <= '2016';
复制代码
  • 可优化为值计算，以下：
select * from doc where create_time <= '2016-01-01';
复制代码
  • 好比下面的 SQL 语句：
select * from order where date < = CURDATE()；
复制代码
  • 能够优化为：
select * from order where date < = '2018-01-2412:00:00';
复制代码

七、强制类型转换会全表扫描

  • 字符串类型不加单引号会致使索引失效，由于mysql会本身作类型转换,至关于在索引列上进行了操做。
  • 若是 phone 字段是 varchar 类型，则下面的 SQL 不能命中索引。
select * from user where phone=13800001234
复制代码
  • 能够优化为：
select * from user where phone='13800001234';
复制代码

八、更新十分频繁、数据区分度不高的列不宜创建索引

  • 更新会变动 B+ 树，更新频繁的字段创建索引会大大下降数据库性能。post

  • “性别”这种区分度不大的属性，创建索引是没有什么意义的，不能有效过滤数据，性能与全表扫描相似。性能

  • 通常区分度在80%以上的时候就能够创建索引，区分度可使用 count(distinct(列名))/count(*) 来计算。优化

九、利用覆盖索引来进行查询操做，避免回表，减小select * 的使用

  • 覆盖索引：查询的列和所创建的索引的列个数相同，字段相同。
  • 被查询的列，数据能从索引中取得，而不用经过行定位符 row-locator 再到 row 上获取，即“被查询列要被所建的索引覆盖”，这可以加速查询速度。
  • 例如登陆业务需求，SQL语句以下。
Select uid, login_time from user where login_name=? and passwd=?
复制代码
  • 能够创建(login_name, passwd, login_time)的联合索引，因为 login_time 已经创建在索引中了，被查询的 uid 和 login_time 就不用去 row 上获取数据了，从而加速查询。

十、索引不会包含有NULL值的列

  • 只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。因此咱们在数据库设计时，尽可能使用not null 约束以及默认值。

十一、is null, is not null没法使用索引

十二、若是有order by、group by的场景，请注意利用索引的有序性

  1. order by 最后的字段是组合索引的一部分，而且放在索引组合顺序的最后，避免出现file_sort 的状况，影响查询性能。
  • 例如对于语句 where a=? and b=? order by c，能够创建联合索引(a,b,c)。
  1. 若是索引中有范围查找，那么索引有序性没法利用，如 WHERE a>10 ORDER BY b;，索引(a,b)没法排序。

1三、使用短索引（前缀索引）

  • 对列进行索引，若是可能应该指定一个前缀长度。例如，若是有一个CHAR(255)的列，若是该列在前10个或20个字符内，能够作到既使得前缀索引的区分度接近全列索引，那么就不要对整个列进行索引。由于短索引不只能够提升查询速度并且能够节省磁盘空间和I/O操做，减小索引文件的维护开销。可使用count(distinct leftIndex(列名, 索引长度))/count(*) 来计算前缀索引的区分度。

  • 但缺点是不能用于 ORDER BY 和 GROUP BY 操做，也不能用于覆盖索引。

  • 不过不少时候不必对全字段创建索引，根据实际文本区分度决定索引长度便可。

1四、利用延迟关联或者子查询优化超多分页场景

  • MySQL 并非跳过 offset 行，而是取 offset+N 行，而后返回放弃前 offset 行，返回 N 行，那当 offset 特别大的时候，效率就很是的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行 SQL 改写。
  • 示例以下，先快速定位须要获取的id段，而后再关联:
selecta.* from 表1 a,(select id from 表1 where 条件 limit100000,20 ) b where a.id=b.id；
复制代码

1五、若是明确知道只有一条结果返回，limit 1 可以提升效率

  • 好比以下 SQL 语句：
select * from user where login_name=?;
复制代码
  • 能够优化为：
select * from user where login_name=? limit 1
复制代码
  • 本身明确知道只有一条结果，但数据库并不知道，明确告诉它，让它主动中止游标移动。

1六、超过三个表最好不要 join

  • 须要 join 的字段，数据类型必须一致，多表关联查询时，保证被关联的字段须要有索引。

  • 例如：left join是由左边决定的，左边的数据必定都有，因此右边是咱们的关键点，创建索引要建右边的。固然若是索引在左边，能够用right join。

1七、单表索引建议控制在5个之内

1八、SQL 性能优化 explain 中的 type：至少要达到 range 级别，要求是 ref 级别，若是能够是 consts 最好

  • consts：单表中最多只有一个匹配行（主键或者惟一索引），在优化阶段便可读取到数据。

  • ref：使用普通的索引（Normal Index）。

  • range：对索引进行范围检索。

  • 当 type=index 时，索引物理文件全扫，速度很是慢。

1九、业务上具备惟一特性的字段，即便是多个字段的组合，也必须建成惟一索引

  • 不要觉得惟一索引影响了 insert 速度，这个速度损耗能够忽略，但提升查找速度是明显的。另外，即便在应用层作了很是完善的校验控制，只要没有惟一索引，根据墨菲定律，必然有脏数据产生。

20.建立索引时避免如下错误观念

  1. 索引越多越好，认为须要一个查询就建一个索引。

  2. 宁缺勿滥，认为索引会消耗空间、严重拖慢更新和新增速度。

  3. 抵制唯一索引，认为业务的唯一性一概须要在应用层经过“先查后插”方式解决。

  4. 过早优化，在不了解系统的状况下就开始优化。

索引选择性与前缀索引

  • 既然索引能够加快查询速度，那么是否是只要是查询语句须要，就建上索引？答案是否认的。由于索引虽然加快了查询速度，但索引也是有代价的：索引文件自己要消耗存储空间，同时索引会加剧插入、删除和修改记录时的负担，另外，MySQL在运行时也要消耗资源维护索引，所以索引并非越多越好。通常两种状况下不建议建索引。

  • 第一种状况是表记录比较少，例如一两千条甚至只有几百条记录的表，不必建索引，让查询作全表扫描就行了。至于多少条记录才算多，这个我的有我的的见解，我我的的经验是以2000做为分界线，记录数不超过 2000能够考虑不建索引，超过2000条能够酌情考虑索引。

  • 另外一种不建议建索引的状况是索引的选择性较低。所谓索引的选择性（Selectivity），是指不重复的索引值（也叫基数，Cardinality）与表记录数（#T）的比值：

Index Selectivity = Cardinality / #T
复制代码
  • 显然选择性的取值范围为(0, 1]``，选择性越高的索引价值越大，这是由B+Tree的性质决定的。例如，employees.titles表，若是title`字段常常被单独查询，是否须要建索引，咱们看一下它的选择性：
SELECT count(DISTINCT(title))/count(*) AS Selectivity FROM employees.titles;
+-------------+
| Selectivity |
+-------------+
|      0.0000 |
+-------------+
复制代码

  • title的选择性不足0.0001（精确值为0.00001579），因此实在没有什么必要为其单独建索引。

  • 有一种与索引选择性有关的索引优化策略叫作前缀索引，就是用列的前缀代替整个列做为索引key，当前缀长度合适时，能够作到既使得前缀索引的选择性接近全列索引，同时由于索引key变短而减小了索引文件的大小和维护开销。下面以employees.employees表为例介绍前缀索引的选择和使用。

  • 假设employees表只有一个索引<emp_no>，那么若是咱们想按名字搜索一我的，就只能全表扫描了：

EXPLAIN SELECT * FROM employees.employees WHERE first_name='Eric' AND last_name='Anido';
+----+-------------+-----------+------+---------------+------+---------+------+--------+-------------+
| id | select_type | table     | type | possible_keys | key  | key_len | ref  | rows   | Extra       |
+----+-------------+-----------+------+---------------+------+---------+------+--------+-------------+
|  1 | SIMPLE      | employees | ALL  | NULL          | NULL | NULL    | NULL | 300024 | Using where |
+----+-------------+-----------+------+---------------+------+---------+------+--------+-------------+
复制代码
  • 若是频繁按名字搜索员工，这样显然效率很低，所以咱们能够考虑建索引。有两种选择，建<first_name>或<first_name, last_name>，看下两个索引的选择性：
SELECT count(DISTINCT(first_name))/count(*) AS Selectivity FROM employees.employees;
+-------------+
| Selectivity |
+-------------+
|      0.0042 |
+-------------+
SELECT count(DISTINCT(concat(first_name, last_name)))/count(*) AS Selectivity FROM employees.employees;
+-------------+
| Selectivity |
+-------------+
|      0.9313 |
+-------------+
复制代码
  • <first_name>显然选择性过低，``<first_name, last_name>选择性很好，可是first_name和last_name加起来长度为30，有没有兼顾长度和选择性的办法？能够考虑用first_name和last_name的前几个字符创建索引，例如<first_name, left(last_name, 3)>`，看看其选择性：
SELECT count(DISTINCT(concat(first_name, left(last_name, 3))))/count(*) AS Selectivity FROM employees.employees;
+-------------+
| Selectivity |
+-------------+
|      0.7879 |
+-------------+

复制代码
  • 选择性还不错，但离0.9313仍是有点距离，那么把last_name前缀加到4：
SELECT count(DISTINCT(concat(first_name, left(last_name, 4))))/count(*) AS Selectivity FROM employees.employees;
+-------------+
| Selectivity |
+-------------+
|      0.9007 |
+-------------+
复制代码
  • 这时选择性已经很理想了，而这个索引的长度只有18，比<first_name, last_name>短了接近一半，咱们把这个前缀索引建上：
ALTER TABLE employees.employees
ADD INDEX `first_name_last_name4` (first_name, last_name(4));
复制代码
  • 此时再执行一遍按名字查询，比较分析一下与建索引前的结果：
SHOW PROFILES;
+----------+------------+---------------------------------------------------------------------------------+
| Query_ID | Duration   | Query                                                                           |
+----------+------------+---------------------------------------------------------------------------------+
|       87 | 0.11941700 | SELECT * FROM employees.employees WHERE first_name='Eric' AND last_name='Anido' |
|       90 | 0.00092400 | SELECT * FROM employees.employees WHERE first_name='Eric' AND last_name='Anido' |
+----------+------------+---------------------------------------------------------------------------------+
复制代码

  • 性能的提高是显著的，查询速度提升了120多倍。

  • 前缀索引兼顾索引大小和查询速度，可是其缺点是不能用于ORDER BY和GROUP BY操做，也不能用于Covering index（即当索引自己包含查询所需所有数据时，再也不访问数据文件自己）。

总结

  • 本文主要讲了索引优化的二十个原则，但愿读者喜欢。
  • 本篇文章脑图和PDF文档已经准备好，有须要的伙伴能够回复关键词索引优化获取。

🏆 掘金技术征文|双节特别篇

相关文章
相关标签/搜索
每日一句
    每一个你不满意的现在，都有一个你没有努力的曾经。
本站公众号
   欢迎关注本站公众号,获取更多信息
联系我们 最近搜索 最新文章 沪ICP备13005482号-10 MyBatis教程 SQL 教程 MySQL教程 Java 教程 Thymeleaf 教程 Hibernate教程 Spring教程 Redis教程