为什么 MySQL 联合索引必须满足最左前缀原则？

说起MySQL共享索引，确实让我遇到了很多坑。
记得那年我在一家公司接了一个项目，需要根据用户名和密码查询用户信息。
我首先考虑简单性并创建了一个共享索引（用户名，密码）。
结果在一次查询的时候发现数据量变大之后查询速度变得特别慢。
原来最左边前缀的原理被忘记了。

当时我傻乎乎的以为联合索引可以随便用，结果查询条件中并没有包含用户名，只用了密码。
结果是全表扫描，速度非常慢。
当时我很担心数据库，花了几分钟才得到结果。

后来我意识到联合索引应该按照最左前缀原则建立，查询条件中应该包含第一列。
就像我后来创建了一个索引（用户名，密码）然后查询的时候需要先匹配用户名，这样查询速度就快很多了。

还有一次，在一个电商项目中，我需要根据用户ID和订单号查询订单信息。
在设计索引时，我遵循最左前缀原则：先是ID，再是订单号。
结果优化器自动帮我把查询条件的顺序从（ID，订单号）调整为（订单号，ID），导致查询性能很差。

这个事件让我认识到优化器虽然可以调整WHERE子句中条件的顺序，但仍然必须满足最左前缀原则，不能跳过最左列。

总之，这个最左前缀原则就像设计联合索引时的“道路规则”一样，应该严格遵循。
否则，很容易像以前一样陷入困境。
现在每次我设计索引时我要做的第一件事就是考虑这个原则以确保高效的查询。
哈哈，希望我自己踩过的这些坑对你有帮助。

MySQL最左原则

这是一个陷阱。
查询条件忽略索引最左边的字段。
不要这样做。