为什么 MySQL 优化器无法自动优化联合索引顺序,需要开发者遵循最左前缀原则?
目前主机宝贝上已经有很多关于的文章了,自己在初次阅读这些文章中,也见识到了很多学习思路;那么本文,也希望能帮助到大家,如果阅读完后真的对你学习有帮助,欢迎动动手指,评论留言并分享~
mysql 最左前缀原则揭秘:优化器为何无法自动优化顺序
在使用 mysql 联合索引时,需要遵循最左前缀原则。而有些开发者可能会疑惑,为何优化器不能自动优化顺序,从而忽略最左前缀原则。
最左前缀原则的必要性
最左前缀原则要求索引的第一个字段必须出现在 where 条件中,且不可省略。这是因为 mysql 索引是一种有序结构,只能从左到右扫描。如果 where 条件没有遵循最左前缀原则,优化器就无法直接寻址索引,导致查询效率低下。
导致查询无法使用索引的场景
比如,一个联合索引为 (user_id, created_at),假如我们书写如下 sql 语句:
select * from tweet where created_at < '2021-11-11' and user_id = 1;
如果未遵循最左前缀原则,优化器无法直接寻址索引,只能全表扫描来满足查询请求。
符合最左前缀原则的场景
正确的优化方法是:
SELECT * FROM tweet WHERE user_id = 1 AND created_at < '2021-11-11';
因为 user_id 是联合索引的第一个字段,遵循了最左前缀原则,因此优化器可以通过索引高效定位符合条件的数据。
左前缀原则概括
总的来说,左前缀原则要求联合索引中的第一个字段必须出现在 where 条件中,且后序字段可以任意组合。如 (a, b, c) 索引,where 条件可以是 a, b, c、a, c、a, b、a 等,但不能是 b, c 或 c, a。
未遵循最左前缀原则的表述示例
为了进一步理解,以下为未遵循最左前缀原则的表述:
- created_at < ‘2021-11-11’,仅使用了联合索引 (a, b, c) 中的 created_at 字段。
- user_id = 1,无法使用联合索引 (a, b, c),因为没有使用索引的第一个字段 a。
- where b, c,无法使用联合索引 (a, b, c),因为没有出现索引的第一个字段 a。
今天带大家了解了的相关知识,希望对你有所帮助;关于数据库的技术知识我们会一点点深入介绍,欢迎大家关注主机宝贝公众号,一起学习编程~