Mysql将主键优先于列索引

查询：

索引：

列a

已编制索引，但

列b

未编制索引

列a

具有较高的基数（2M）

整个表由2800万行组成。列a='value1'的行数为22000。 最新的id是2800万。带有

列a='value1'

的最新行的id在25M-25.5M范围内

理想情况下，它应该只扫描这22000行，并给出结果。但是我们已经看到mysql正在扫描这3M行（28M-25M主键id值），然后返回结果

使用mysql

explain

我们发现，如果限制设置为小于20，则会使用

PRIMARY

键，但在此之后，

user\u id

会被优先排序

还有谁见过这种行为吗？是否有任何可以设置的标志可以避免扫描主键？（我们不想使用

强制索引（col\u a\u idx）

。有没有其他方法可以避免这种情况？

虽然如前所述讨论了这个问题，但我建议有更好的方法来优化查询

select * from table_a where col_a = 'value1' and col_b ='value2' order by id desc limit 1

（并删除索引（列a））

这将使查询的运行速度比强制使用

主键（id）

更快

有了这个索引，优化器将自动使用它，并精确地查看1行，而不是28M，而不是22000

如果

列b

是

文本

，此新索引将不起作用。让我们查看

显示创建表

，并请解释列b中的内容类型

---

可能存在数据类型问题。可能索引（col_a）有点愚蠢.

我认为您可能正在寻找，因此基本上我们不想创建另一个索引。查看您的索引提示，这就解决了我们的问题。它开始使用列a索引。列b是带2个值的整数，这就是为什么我们没有在其上创建索引。也不确定使用主键创建索引有多大好处。因为我们没有筛选直接在id上搜索，它将使用额外的索引space@theprikshit-复合（多列）索引与每列上的单独索引不同。它通常要好得多。

INDEX(col_a, col_b, id)