共计 1091 个字符，预计需要花费 3 分钟才能阅读完成。
咱们都晓得在数据库查问时，索引能够极大的进步查问效率。通常在应用的时候，都会针对频繁查问的关键字段建设索引。
比方，当以交易日期（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 上述 SQL 语句，发现没有走索引，而是进行了全表扫描。
但当换一个查问参数时：
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 语句走索引，也同样会生效。
相似的问题，在进行范畴查问（比方 \>、<、>=、<=、in 等条件）时往往会呈现上述情况，而下面提到的临界值依据场景不同也会有所不同。
所以，如果你在我的项目中采纳了上述形式的查问，又心愿它可能走索引，就须要特地留神了。通常须要增加一些其余的限度条件或用其余形式来保障索引的有效性。
博主简介：《SpringBoot 技术底细》技术图书作者，热爱钻研技术，写技术干货文章。
公众号：「程序新视界」，博主的公众号，欢送关注~
技术交换：请分割博主微信号：zhuan2quan