Mysql查询条件为大于时，竟然不走索引失效？

在数据库实战开发的过程中，我们经常会遇到一些这样那样的问题，然后要卡好半天，等问题解决了才发现原来一些细节知识点还是没有掌握好。今天golang学习网就整理分享《Mysql查询条件为大于时，竟然不走索引失效？》，聊聊MySQL、索引、失效，希望可以帮助到正在努力赚钱的你。

我们都知道在数据库查询时，索引可以极大的提高查询效率。通常在使用的时候，都会针对频繁查询的关键字段建立索引。

比如，当以交易日期（trans_date）来查询交易记录时，通常会对该字段添加索引，以便在大量数据的情况下提升查询效率。

针对trans_date字段，创建union_idx_query索引，那么在下面以trans_date为查询条件的语句中，毫无疑问是会走索引的：

select count(1) from A; // 40000

EXPLAIN select * from A where trans_date = '20220222'; 

此时，我们会想当然的以为，只要创建了索引，其他情况的使用同样会走索引。比如下面的查询语句：

select count(1) from t_trans_log_info where trans_date > '20220122'; //11200

EXPLAIN select * from t_trans_log_info where trans_date > '20220122';

上面的查询语句使用了”>“来进行范围的查询，而且trans_date字段同样创建了索引，那么上述SQL语句是否会走索引呢？答案是不一定。

explain

但当换一个查询参数时：

select count(1) from t_trans_log_info where trans_date > '20220222'; //1120

EXPLAIN select * from t_trans_log_info where trans_date > '20120222';

explain

为什么同样的查询语句，只是查询的参数值不同，却会出现一个走索引，一个不走索引的情况呢？

答案很简单：上述索引失效是因为DBMS发现全表扫描比走索引效率更高，因此就放弃了走索引。

也就是说，当Mysql发现通过索引扫描的行记录数超过全表的10%-30%时，优化器可能会放弃走索引，自动变成全表扫描。某些场景下即便强制SQL语句走索引，也同样会失效。

类似的问题，在进行范围查询（比如\>、=、

所以，如果你在项目中采用了上述方式的查询，又希望它能够走索引，就需要特别注意了。通常需要添加一些其他的限制条件或用其他方式来保证索引的有效性。

博主简介：《SpringBoot技术内幕》技术图书作者，酷爱钻研技术，写技术干货文章。

公众号：「程序新视界」，博主的公众号，欢迎关注~

技术交流：请联系博主微信号：zhuan2quan

今天带大家了解了MySQL、索引、失效的相关知识，希望对你有所帮助；关于数据库的技术知识我们会一点点深入介绍，欢迎大家关注golang学习网公众号，一起学习编程~