索引是為了加速數據的檢索，但是不合理的表結構或適應不當則會起到反作用。我們在項目中就遇到過類似的問題，兩個十萬級別的數據表，在做連接查詢的時候，查詢時間達到了7000多秒還沒有查出結果。

首先說明，關聯的字段都已經建立了相對應的索引，在執行計劃的時候發現另外一張表沒有走索引，結果如下圖：

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

優化：

1、當然最直接的想法就是修改兩個表的request_id字段的定義，改成相同即可。修改完成后，執行計劃還是和沒有修改的時候一樣

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

3、修改完成后，執行計劃

關聯查詢走了索引，并且查詢速度從之前的7000多秒沒有查出結果變成了0.25秒出現了結果

結論：

1、表列類型，與where值類型不同會導致全表掃描。

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

2、join的兩個表的字符編碼不同，不能命中索引，會導致笛卡爾積的循環計算(mysql8.0已經做了相關優化，字符集不在影響索引)

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

或 者關注我每天分享技術文章PHP架構師之路?www.zhihu.com

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

總結

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

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。