1. 使用or条件
-- 假设name列有索引,age列没有索引 select * from employees where name = 'john' or age > 30;
在这个查询中,由于age
列没有索引,优化器可能选择全表扫描而不是使用name
列上的索引。
2. 隐式类型转换
-- 假设id是整数类型,但查询中用字符串比较 select * from users where id = '123';
尽管id
列上有索引,但由于隐式类型转换,mysql可能无法使用该索引。
3. 模糊查询的前导通配符
-- 假设username列有索引 select * from users where username like '%john';
因为模式以%
开头,所以索引不能被用于加速查询。
4. 对索引列进行函数操作
-- 假设created_at列有索引 select * from orders where year(created_at) = 2020;
对created_at
应用了year()
函数,导致索引失效。
5. 复合索引未遵循最左前缀原则
-- 创建一个复合索引 (first_name, last_name) create index idx_name on employees(first_name, last_name); -- 查询只用了last_name select * from employees where last_name = 'doe';
由于查询条件没有从复合索引的第一个字段开始,因此不会使用这个索引。
6. 索引选择性低
-- 假设status列有很多重复值(如active/inactive),并有索引 select * from accounts where status = 'active';
如果status
列的选择性很低(即大量记录具有相同的值),mysql可能会选择全表扫描而非索引扫描。
7. 索引长度超出限制
-- 假设text_column是一个非常长的varchar列,并尝试创建一个过长的索引 create index idx_long_text on articles(text_column(255));
如果text_column
的长度超过了innodb索引的最大长度,索引创建将会失败。
8. 表统计信息过期
-- 如果长时间没有分析表,统计信息可能不准确 analyze table employees;
定期运行analyze table
可以帮助优化器做出更好的决策。
9. 索引列参与了null检查
-- 假设nullable_column允许null值,并有索引 select * from items where nullable_column is null;
虽然b树索引可以处理is null
,但如果设计不当,这仍可能导致索引未被使用。
10. 查询结果集过大
-- 即使有索引,如果查询返回的结果集非常大 select * from logs where log_date between '2020-01-01' and '2020-12-31';
在这种情况下,全表扫描可能是更高效的选择。
以上例子展示了不同的场景下如何影响索引的使用。为了确保索引能有效工作,需要仔细考虑这些因素,并通过explain
命令验证查询计划
到此这篇关于mysql什么情况下不会命中索引的文章就介绍到这了,更多相关 mysql不会命中索引内容请搜索代码网以前的文章或继续浏览下面的相关文章希望大家以后多多支持代码网!
海报
117