如果是查询中的最后一个字段-MySQL，那么需要索引表的一列吗？

假设我有一个包含3列（c1、c2、c3）的表（t1），我添加了如下索引：

ALTER TABLE `t1` ADD INDEX `IDX_c1_c2` USING BTREE (`c1`, `c2`);

我知道，如果我使用索引进行此查询，并且效果非常好：

SELECT * FROM `t1` where c1 = "foo" AND c2 = "bar"

但是，这个问题呢

SELECT * FROM `t1` where c1 = "foo" AND c2 = "bar" AND c3 = "foobar"

MySQL引擎会使用索引来改进查询，还是会忽略索引？我的意思是，为了使用索引，整个查询必须与索引匹配，或者我可以利用查询前两列的索引

[更新]-最后一个查询实际上是这样的（日期只是一个示例）：

---

为了简单起见，您的现有索引仍将使用，但第三列将独立解析。查询处理器将生成一些计划，引擎将接受最佳计划以继续。仍然将第三列作为索引肯定会夸耀其表现

建议 如果在查询中使用相等条件，则转到基于散列的索引而不是Btree，它提供了这些问题的所有答案，以及更多答案

• 索引（c1，c2）

  （按任意顺序）适用于所有这些情况

• （c1、c2、c3）

  适用于所有这些情况；第二和第三组的效果更好。对于

  （c2、c1、c3）

  ，同上
• 其他订单对于您的第三次查询不起作用--

  =

  部分必须放在第一位，而不是“范围”（例如
  ）

---

好处：如果表中确实只有这3列，那么

（c1、c2、c3）

就是“覆盖”。这意味着它可以在索引树中执行整个查询，而不需要触摸数据树。

谢谢你的回答，让我编辑了这篇文章。查看更新，最后一个查询使用'>'运算符表示日期。我认为为日期编制索引不是一个好主意，所以我想用前两列来优化搜索，然后在日期前搜索结果的大小要小得多。据我所知，只有两个索引。写入操作将花费更多的时间，因为需要更新的字段越多，占用的空间也越多。除此之外，我看不出有什么问题。如果这三个都在查询中运行，我认为在建立第三列索引时也没有问题。但是如果你的系统在现有设计下运行良好，那么现在就不要修改它。对于点查询，哈希索引只比BTree快一点点。但是哈希在MySQL中不可用。（好的，只有一个例外。）

SELECT * FROM `t1` where c1 = "foo" AND c2 = "bar" AND c3 > "2016-11-26 07:37:47"