背景

在檢查數(shù)據(jù)庫的執(zhí)行效率的時(shí)候，發(fā)現(xiàn)了一條查詢極慢的查詢sql。sql的例子如下：

EXPLAIN SELECT * FROM user_point_detail_info WHERE 1=1 AND deleted = FALSE AND app_id = 2010001 AND point > 10 AND add_time BETWEEN "2021-03-12 17:00:00" AND "2021-03-12 17:51:00" ORDER BYuser_id DESC, point

因?yàn)橹坝衷诠渲趸騝sdn的時(shí)候逛到過一個(gè)帖子，說是如果在where 后面添加 1=1這種無意義條件會(huì)影響數(shù)據(jù)庫的索引的使用，導(dǎo)致掃描全表的情況發(fā)生。本著好吃懶做坐享其成的原則就對此結(jié)論深以為然，正要著手修改這個(gè)查詢的sql拼接的時(shí)候想到對此結(jié)論進(jìn)行一番測試。看看where 1 = 1這個(gè)方便大家對sql 條件進(jìn)行拼接的trick 是否會(huì)影響查詢的時(shí)候?qū)λ饕氖褂谩?/p>

實(shí)測

搬出SQL語句分析大法explain，對加1=1和不加1=1情況的索引使用情況進(jìn)行分析。

不含where 1=1的條件下：

可以看到possible_keys（可能使用的索引） 和 key（實(shí)際使用的索引）都使用到了索引進(jìn)行檢索。

不含where 1=1的條件下：

結(jié)果是與不加這個(gè)條件的情況是一樣的。

結(jié)論：

where 1=1 不影響查詢效率

分析:

我們寫的sql指令會(huì)被mysql 進(jìn)行解析優(yōu)化成自己的處理指令，在這個(gè)過程中1 = 1這類無意義的條件將會(huì)被優(yōu)化。使用explain EXTENDED sql 進(jìn)行校對，發(fā)現(xiàn)確實(shí)where1=1這類條件會(huì)被mysql的優(yōu)化器所優(yōu)化掉。

創(chuàng)作挑戰(zhàn)賽新人創(chuàng)作獎(jiǎng)勵(lì)來咯，堅(jiān)持創(chuàng)作打卡瓜分現(xiàn)金大獎(jiǎng)

總結(jié)

以上是生活随笔為你收集整理的MySQL 添加where 1= 1 是否会引起索引失效的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。