我有一个包含150k行数据的表，我有一列UNIQUE INDEX，它有一个类型VARCHAR(10)并存储10位数的帐号。MySQL索引有时不被使用
现在，每当我查询，是一个简单的一个：
SELECT * FROM table WHERE account_number LIKE '0103%'
它导致30,000行，当我运行一个EXPLAIN我的查询，也没有任何使用索引。
但是当我做：
SELECT * FROM table WHERE account_number LIKE '0104%'
它导致4000个+排，使用的索引。
任何人都可以解释这一点？
I'm using MySQL 5.7 Percona XtraDB.
30K +/15万> 20％，我想这是更快地做表扫描。从8.2.1.19 Avoiding Full Table Scans：
从EXPLAIN显示了所有的类型列时MySQL使用全表扫描来解决查询的输出。这通常发生在以下条件下：
您正在通过另一列使用低基数（许多行与键值相匹配）的键。 在这种情况下，MySQL假定通过使用密钥，它可能会执行许多密钥查找，并且表扫描会更快。
如果你并不需要所有的值尝试使用：的
SELECT account_number FROM table WHERE account_number LIKE '0103%'
代替SELECT *。那么你的索引将成为覆盖索引，优化器应该总是使用它（只要WHERE条件是SARGable）。
谢谢，我也这么认为，索引也显示在possible_keys但没有使用，猜测我不应该问优化器。 –
@JohnPangilinan优化器并不总是正确的。有时候它会产生非常愚蠢的计划。 –
lad2025是正确的。数据库正试图进行智能优化。
与基准：
SELECT * FROM table FORCE INDEX(table_index) WHERE account_number LIKE '0103%'
，看看谁是聪明:-)你可以尝试在你的手质问优化。这是什么索引提示...
https://dev.mysql.com/doc/refman/5.7/en/index-hints.html
大多数数据库使用B树进行索引。在这种情况下，数据库优化器不使用索引，因为它的扫描速度更快，无需索引。像@ lad2025解释。
您的数据库列是唯一的，我认为您的索引基数很高。但是，由于您的查询使用类似的过滤器，数据库优化器决定您选择不使用索引。
您可以使用try force index来查看结果。你使用具有唯一索引的varchar。我会选择另一种数据类型或更改索引类型。如果您的表格只包含数字，则将其更改为数字。这将有助于优化你的查询。
在某些情况下，如果您必须使用像您可以使用全文索引。
如果您在优化查询和表格方面需要帮助。向我们提供更多信息以及您想从表格中获取哪些信息。
'30k +/150k'> 20％，我猜这是更快的做表扫描。 – lad2025
为什么使用4k行索引正被使用？它虽然小于30k。 –
'为什么使用4k行，索引仍然没有被使用？vs'它导致4000多行，使用INDEX。'请决定 – lad2025