MySQL 查询优化（二） 优化原则

从上向下分别是：连接层，服务层，引擎层，存储层 存储引擎就是存储数据，建立索引，更新/查询数据等技术的实现方式。存储引擎是基于表的，而不是基于库的，所以存储引擎也可以被称为表类型。 show create table ‘表名’； SHOW ENGINES;

• 从上表看出只有InnoDB支持事务处理！

innodb 支持事务，支持行级锁，支持外键 MyISAM MEMORY 存储在内存中，通常用作临时表   innoDB是一种兼顾高可靠性和高性能的通用存储引擎，在MySQL5.5之后，InnoDB是默认的MySQL存储引擎。 InnoDB的特点： DML 操作遵循ACID模型，支持事务； 行级锁，提高并发访问性能； 支持外键FOREIGN KEY 约束，保证数据的完整性和正确性。 DML:数据操纵语言是用于数据库操作,对数据库其中的对象和数据运行访问工作的编程语句 acid即原子性、一致性、隔离性、持久性   InnoDB的文件：xxx.idb InnoDB引擎的每张表都会对应这样一个表空间文件，存储该表的结构（frm，sdi）,数据和索引。 在Mysql8.0之前，frm文件是单独存在的文件，8.0以后表结构存储到sdi文件中，sdi文件又融入到.idb文件中 参数：innodb_file_per_table 为ON是说明，每一张表都对应一个表空间文件，不共享表空间文件   InnoDB中page是操作磁盘控件的最小单元。 page中包含索引页和数据页。   MyISAM 特点： 1.不支持事务，不支持外键 2.支持表锁，不支持行级锁 3.访问速度快 MySIAM 文件：.MYD,.MYI,.sdi .sdi 文件存储表结构信息 .MYD 文件存储表数据 .MYI存储索引   MEMORY 引擎 介绍：Memory引擎的表数据是存储在内存中，由于硬件问题或断电问题的影响，只能将这些表作为临时表或者缓存使用。 特点：内存存放，支持hash索引（默认） MEMORY 文件：存储表结构信息   存储引擎选择 InnoDB：是Mysql的默认存储引擎，支持事务、外键。如果应用对事务的完整性有比较高的要求，在并发条件下要求数据的一致性，数据操作除了插入和查询之外，还包含跟多的更新、删除操作，那么InnoDB存储引擎是比较合适的选择。 MyISAM:如果应用是以读操作和插入操作为主，只有很少的更新和删除，并且对事务的完整性、并发性要求不是很高，那么选择MySIAM存储引擎是非常合适的。（该场景用mogodb更合适） MEMORY:将所有数据保存在内存中，访问速度快，通常用于临时表及缓存。MEMORY的缺陷就是对表的大小有限制，太大的表无法缓存在内存中，而且无法保障数据的安全性。（该场景用redis更合适）     1.最左前缀原则 2.存储引擎不能使用索引中范围条件右边的列 3.尽量使用覆盖索引（只访问索引的查询（索引列包含查询列）），减少使用select * 4.mysql 在使用不等于（！=或者<>）,not in,not exists的时候无法使用索引会导致全表扫描<小于 ，>大于，<=,>=这些，MySQL内部优化器会根据检索比例，表大小等多个因素整体平谷是否使用索引     联合索引的存储结构 索引时帮助MySQL高效获取数据的排好序的数据结构 以三个字段的联合索引为例，首先按照第一个字段排序   索引规约

1. 【强制】业务上具有唯一特性的字段，即使是多个字段的组合，也必须建成唯一索引。

说明：不要以为唯一索引影响了 insert 速度，这个速度损耗可以忽略，但提高查找速度是明显的；另外，即使在应用层做了非常完善的校验控制，只要没有唯一索引，根据墨菲定律，必然有脏数据产生。

2. 【强制】超过三个表禁止 join。需要 join 的字段，数据类型必须绝对一致；多表关联查询时，保证被关联的字段需要有索引。

说明：即使双表 join 也要注意表索引、SQL 性能。

3. 【强制】在 varchar 字段上建立索引时，必须指定索引长度，没必要对全字段建立索引，根据实际文本区分度决定索引长度即可。

说明：索引的长度与区分度是一对矛盾体，一般对字符串类型数据，长度为 20 的索引，区分度会高达 90%以上，可以使用 count(distinct left(列名, 索引长度))/count(*)的区分度来确定。

4. 【强制】页面搜索严禁左模糊或者全模糊，如果需要请走搜索引擎来解决。

说明：索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。

5. 【推荐】如果有 order by 的场景，请注意利用索引的有序性。order by 最后的字段是组合索引的一部分，并且放在索引组合顺序的最后，避免出现 file_sort 的情况，影响查询性能。

正例：where a=? and b=? order by c; 索引：a_b_c 反例：索引中有范围查找，那么索引有序性无法利用，如：WHERE a>10 ORDER BY b; 索引a_b 无法排序。

6. 【推荐】利用覆盖索引来进行查询操作，避免回表。

说明：如果一本书需要知道第 11 章是什么标题，会翻开第 11 章对应的那一页吗？目录浏览一下就好，这个目录就是起到覆盖索引的作用。 正例：能够建立索引的种类分为主键索引、唯一索引、普通索引三种，而覆盖索引只是一种查询的一种效果，用 explain 的结果，extra 列会出现：using index。

7. 【推荐】利用延迟关联或者子查询优化超多分页场景。

说明：MySQL 并不是跳过 offset 行，而是取 offset+N 行，然后返回放弃前 offset 行，返回N 行，那当 offset 特别大的时候，效率就非常的低下，要么控制返回的总页数，要么对超过特定阈值的页数进行 SQL 改写。 正例：先快速定位需要获取的 id 段，然后再关联： SELECT a.* FROM 表 1 a, (select id from 表 1 where 条件 LIMIT 100000,20 ) b where a.id=b.id

8. 【推荐】SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，如果可以是 consts最好。

说明：

• consts 单表中最多只有一个匹配行（主键或者唯一索引），在优化阶段即可读取到数据。
• ref 指的是使用普通的索引（normal index）。
• range 对索引进行范围检索。

反例：explain 表的结果，type=index，索引物理文件全扫描，速度非常慢，这个 index 级别比较 range 还低，与全表扫描是小巫见大巫。

9. 【推荐】建组合索引的时候，区分度最高的在最左边。

正例：如果 where a=? and b=? ，如果 a 列的几乎接近于唯一值，那么只需要单建 idx_a索引即可。 说明：存在非等号和等号混合时，在建索引时，请把等号条件的列前置。如：where c>? and d=? 那么即使 c 的区分度更高，也必须把 d 放在索引的最前列，即索引 idx_d_c。

10. 【推荐】防止因字段类型不同造成的隐式转换，导致索引失效。