索引是為了加速數(shù)據(jù)的檢索，但是不合理的表結(jié)構(gòu)或適應(yīng)不當(dāng)則會起到反作用。我們在項(xiàng)目中就遇到過類似的問題，兩個(gè)十萬級別的數(shù)據(jù)表，在做連接查詢的時(shí)候，查詢時(shí)間達(dá)到了7000多秒還沒有查出結(jié)果。

首先說明，關(guān)聯(lián)的字段都已經(jīng)建立了相對應(yīng)的索引，在執(zhí)行計(jì)劃的時(shí)候發(fā)現(xiàn)另外一張表沒有走索引，結(jié)果如下圖：

具體描述為：Range checked for each record (index map: 0x1); Not exists

優(yōu)化：

1、當(dāng)然最直接的想法就是修改兩個(gè)表的request_id字段的定義，改成相同即可。修改完成后，執(zhí)行計(jì)劃還是和沒有修改的時(shí)候一樣

2、由于兩張表中的字段類型都是varchar類型的，所以猜測會存在字符集的問題，在Navicat中查看其排序規(guī)則不同

3、修改完成后，執(zhí)行計(jì)劃

關(guān)聯(lián)查詢走了索引，并且查詢速度從之前的7000多秒沒有查出結(jié)果變成了0.25秒出現(xiàn)了結(jié)果

結(jié)論：

1、表列類型，與where值類型不同會導(dǎo)致全表掃描。

例：phone char(11) select * from table where phone=12345678901;

2、join的兩個(gè)表的字符編碼不同，不能命中索引，會導(dǎo)致笛卡爾積的循環(huán)計(jì)算(mysql8.0已經(jīng)做了相關(guān)優(yōu)化，字符集不在影響索引)

以上內(nèi)容希望幫助到大家，很多PHPer在進(jìn)階的時(shí)候總會遇到一些問題和瓶頸，業(yè)務(wù)代碼寫多了沒有方向感，不知道該從那里入手去提升，對此我整理了一些資料，包括但不限于：分布式架構(gòu)、高可擴(kuò)展、高性能、高并發(fā)、服務(wù)器性能調(diào)優(yōu)、TP6，laravel，YII2，Redis，Swoole、Swoft、Kafka、Mysql優(yōu)化、shell腳本、Docker、微服務(wù)、Nginx等多個(gè)知識點(diǎn)高級進(jìn)階干貨需要的可以免費(fèi)分享給大家

或 者關(guān)注我每天分享技術(shù)文章PHP架構(gòu)師之路?www.zhihu.com

來源：https://www.cnblogs.com/tm2015/p/11310451.html

總結(jié)

以上是生活随笔為你收集整理的mysql没加引号导致全表扫描_mysql隐蔽的索引规则导致数据全表扫描的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

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