MySQL中，倒排索引能否替代Elasticsearch实现高效的搜索功能？

mysql中and的用法 mysql and条件查询示例

MySQL导致索引失效的情况有哪些

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

嗯，我听你讲了这个共享索引的最左前缀原理。
看上去有点复杂，但实际操作起来确实是个陷阱。
我给大家讲一下我遇到的具体情况。

一年前我在上海做一个项目。
数据库表很大，大概有八九百万条数据。
我们有一个查询，用户通过用户 ID 和产品类别搜索特定产品。
我建立了一个共享索引（id_user，类别）。
结果呢？用户经常只检查类别而不传递user_id。
那么这个索引就没啥用了，因为B+树是从左到右的，必须先匹配user_id。
那一次，因为这个，查询速度慢了一倍，真是让人头疼。

另一个例子是去年在深圳的另一个项目。
有一个表有很多字段，所以我创建了一个共享索引（时间、状态、类型）。
该业务要求我优化 WHERE status = 'active' AND type = 'A' 的查询。
你看，它直接就过了最左边一栏的时间。
我检查了执行计划，发现这个索引根本就没有被取到。
我说你的索引是白建的，你需要加时间。
他们一开始也不相信，就尝试了一下，果然速度更快了。
这次我找到了最左边的前缀。

还有一种情况。
一年前，我在杭州搭建一个电子商务系统。
表数据更大，有几千万条。
有一个查询WHERE order_id > 1 0000 AND user_id = 1 2 3 我建立的索引是(user_id, order_id)。
事实证明，由于order_id是范围查询，优化器只能使用user_id部分，而order_id仍然要扫描全表。
那次我改成了(order_id, user_id)，性能提高了。
你看，这个顺序不能乱。

所以最左前缀原则不是一个神话，而是一个真正的陷阱。
在建立索引时，您需要清楚地考虑用户将如何搜索。
最常用的字段位于左侧。
不要随意跳到中间列，否则索引就没用了。
优化器足够聪明，但它不是万能的，应该遵守这个规则。

你记住，建立索引时，不要只看理论，要运行实际的查询来看看执行计划如何进行。
只是尽量避免我踩过的陷阱。