当前位置：首页 > article >正文

【MySQL索引】4索引优化

article 2024/11/15 13:50:01

索引优化

1 关联查询优化

左连接LEFT JOIN

LEFT JOIN 右边是我们的关键点,一定需要建立索引 .这里是book的card 字段，type建不建索引无所谓。

ALTER TABLE book ADD INDEX Y ( card); #【被驱动表】，可以避免全表扫描
EXPLAIN SELECT SQL_NO_CACHE * FROM `type` LEFT JOIN book ON type.card = book.card;

内连接INNER JOIN

换成 inner join（MySQL自动选择驱动表，一般选取小表为驱动表）
被驱动表加上索引即可。

小结

保证被驱动表的JOIN字段已经创建了索引

需要JOIN 的字段，数据类型保持绝对一致。

LEFT JOIN 时，选择小表作为驱动表，大表作为被驱动表。减少外层循环的次数。

INNER JOIN 时，MySQL会自动将小结果集的表选为驱动表。选择相信MySQL优化策略。

能够直接多表关联的尽量直接关联，不用子查询。(减少查询的趟数)

不建议使用子查询，建议将子查询SQL拆开结合程序多次查询，或使用 JOIN 来代替子查询。

衍生表建不了索引

2 子查询优化

在这里插入图片描述

3 排序优化

order by 优化FileSort ,但使用FileSort不一定慢
在这里插入图片描述

INDEX a_b_c(a,b,c)
order by 能使用索引最左前缀
- ORDER BY a
- ORDER BY a,b
- ORDER BY a,b,c
- ORDER BY a DESC,b DESC,c DESC
如果WHERE使用索引的最左前缀定义为常量，则order by 能使用索引
- WHERE a = const ORDER BY b,c
- WHERE a = const AND b = const ORDER BY c
- WHERE a = const ORDER BY b,c
- WHERE a = const AND b > const ORDER BY b,c
不能使用索引进行排序
- ORDER BY a ASC,b DESC,c DESC /* 排序不一致 */
- WHERE g = const ORDER BY b,c /*丢失a索引*/
- WHERE a = const ORDER BY c /*丢失b索引*/
- WHERE a = const ORDER BY a,d /*d不是索引的一部分*/
- WHERE a in (...) ORDER BY b,c /*对于排序来说，多个相等条件也是范围查询*/

例子：
在这里插入图片描述

4 GROUP BY优化

在这里插入图片描述

5 优化分页查询

1 在索引上完成排序分页操作，最后根据主键关联回原表查询所需要的其他列内容。

EXPLAIN SELECT * FROM student t,(SELECT id FROM student ORDER BY id LIMIT 2000000,10)
a
WHERE t.id = a.id;

2 该方案适用于主键自增的表，可以把Limit 查询转换成某个位置的查询。

EXPLAIN SELECT * FROM student WHERE id > 2000000 LIMIT 10;

6 优先考虑覆盖索引

在这里插入图片描述

7 对字符串添加前缀索引的考虑

使用前缀索引，定义好长度，就可以做到既节省空间，又不用额外增加太多的查询成本。前面已经讲过区分度，区分度越高越好。因为区分度越高，意味着重复的键值越少。

使用前缀索引就用不上覆盖索引对查询性能的优化了，这也是你在选择是否使用前缀索引时需要考虑的一个因素。

8 索引下推

Index Condition Pushdown(ICP)是MySQL 5.6中新特性，是一种在存储引擎层使用索引过滤数据的一种优化方式。ICP可以减少存储引擎访问基表的次数以及MySQL服务器访问存储引擎的次数。

使用前，存储层多返回了需要被index filter过滤掉的整行记录
使用ICP后，直接就去掉了不满足index filter条件的记录，省去了他们回表和传递到server层的成本。
ICP的加速效果取决于在存储引擎内通过 ICP筛选掉的数据的比例

在这里插入图片描述

9 普通索引 vs 唯一索引

普通索引和唯一索引应该怎么选择？其实，这两类索引在查询能力上是没差别的，主要考虑的是对更新性能的影响。所以，建议你尽量选择普通索引。
在实际使用中会发现，普通索引和 change buffer 的配合使用，对于数据量大的表的更新优化还是很明显的。
如果所有的更新后面，都马上伴随着对这个记录的查询，那么你应该关闭change buffer 。而在其他情况下，change buffer都能提升更新性能。
由于唯一索引用不上change buffer的优化机制，因此如果业务可以接受，从性能角度出发建议优先考虑非唯一索引。但是如果"业务可能无法确保"的情况下，怎么处理呢？

首先，业务正确性优先。我们的前提是“业务代码已经保证不会写入重复数据”的情况下，讨论性能问题。如果业务不能保证，或者业务就是要求数据库来做约束，那么没得选，必须创建唯一索引。这种情况下，本节的意义在于，如果碰上了大量插入数据慢、内存命中率低的时候，给你多提供一个排查思路。
然后，在一些“ 归档库 ”的场景，你是可以考虑使用唯一索引的。比如，线上数据只需要保留半年，然后历史数据保存在归档库。这时候，归档数据已经是确保没有唯一键冲突了。要提高归档效率，可以考虑把表里面的唯一索引改成普通索引。