SQL優化(2):別讓like要了咱的命

2020-10-21 Q程式設計師

帶有like的sql語句是否會觸發索引

印象中使用like就是跳過索引，進行全表掃描，一表1億數據的表，程序直接趴下了。

其實非也，mysql原生是支持like前綴索引的

前綴索引原理

用索引數據全掃描取代表的全掃描。

因為索引全掃描的代價是全表掃描的1/N (即索引塊數與數據塊數的比例），表越大，優化效果越明顯。

實例

like '%Quentin%'; 不會觸發

like '%Quentin'; 不會觸發

like 'Quentin%'; 會觸發

不支持後綴索引怎麼辦

上邊是前綴索引，後綴索引不支持了，怎麼辦。

新增一列，存儲該欄位的反轉。比如原欄位是abcd，取反存儲為dcba，查詢%bcd改成查dcb%。有點浪費空間，不過也算是一種辦法，空間換時間。

注意了哈

大多大廠公司已經規定禁止Mysql sql 語句使用like 關鍵字，記得在新浪時誰寫個like把程序卡住了，直接收拾收拾回家等通知吧。

感謝收看本期Q程式設計師說，最後別忘點讚加關注哈！我接著繼續整，有啥不爽留言。

相關焦點

  • 女朋友都能看懂的,SQL優化乾貨
    一、什麼情況會不走索引1、模糊查詢，在欄位開頭模糊select * from teacher where name like '%老師'優化：在欄位後面使用模糊查詢select * from teacher where name like '李%'如果一定要在欄位開頭模糊查詢，那可以使用INSTR(str,substr)意思是：在字符串str裡面,字符串substr出現的第一個位置(index)，index
  • SQL優化案例（2）：OR條件優化
    隨後上一篇文章《 SQL優化案例（1）：隱式轉換》的介紹，此處內容圍繞OR的優化展開。2.場景解析從查詢條件中可以研磨令牌和uid過濾性都非常好，但是由於使用了，或者，需要採用索引合併的方法才能獲得比較好的性能。
  • Mysql 性能調優之sql和索引優化
    結論：在執行常量等值查詢時，改變索引列的順序並不會更改explain的執行結果，因為mysql底層優化器會進行優化，但是推薦按照索引順序列編寫sql語句。使用Mysql慢查詢日誌對有效率問題的SQL進行監控# 查看包含log的參數show variables like '%log%';#查看慢查詢日誌是否開啟show variables like 'slow_query_log';#查看慢查詢日誌存儲位置show variables like 'slow_query_log_file
  • 在查詢領域最強的orm框架sqltoy-orm4.12.2發版了
    為什麼說是最強查詢,下三個命題讓大家來否定最合適最優雅(沒有之一)的動態sql組織模式最具特色的緩存翻譯，大幅減少表關聯簡化sql、提升性能最強的分頁優化（沒有之一），不信你試圖拿一個更強的來反駁開源地址：
  • SQL查詢優化分析（900W+數據，從17s到300ms）
    有一張財務流水錶，未分庫分表，目前的數據量為9555695，分頁查詢使用到了limit，優化之前的查詢耗時16 s 938 ms (execution: 16 s 831 ms, fetching: 107 ms)，按照下文的方式調整SQL後，耗時347 ms (execution
  • mysql優化篇：where中的like和=的性能分析
    >select * from info where id like &39;;2，相同點：like和&34;都可以進行精確查詢，比如下面的例子，從結果上看，都是查詢info表中欄位id等於&39;的結果：select * from info where id like &39;;
  • SQL性能優化，書寫高質量SQL語句
    age) values(&39;,24),(&39;,24),(&39;,24), 複製代碼sql語句的優化主要在於對索引的正確使用，而我們在開發中經常犯的錯誤便是對表進行全盤掃描，一來影響性能，而來耗費時間!
  • 為什麼要使用新一代ORM框架sqltoy-orm
    和jpa模式，查詢就應該要比mybatis的查詢還要強和簡潔、高效、靈活！-- 快速分頁和分頁優化演示 --><sql id=&34;> <!-- 分頁優化器,通過緩存實現查詢條件一致的情況下在一定時間周期內緩存總記錄數量，從而無需每次查詢總記錄數量 --> <!
  • 書寫高性能SQL語句技巧，網友都說好
    作為一名程式設計師，少不了要寫一些sql語句，但每個人寫出來的sql執行效率還是有差距的，功力深厚的人，寫的sql簡潔而且高效，初學者，往往只是實現功能，至於性能問題，可能無從下手。在這裡我將之前在sql優化方面的一些技巧和高效寫法，給大家總結了一下，不說能百分百解決sql性能問題，基本上能解決百分之八十以上的sql性能問題。
  • sqltoy-orm 4.15.3 發版,增強非 sql 模式的查詢功能
    .pageOptimize(new PageOptimize().aliveSeconds(120)));快速了解 sqltoy-orm： sqltoy是全新一代的ORM框架，兼顧jpa對象式操作的優勢，同時極大增強了查詢功能，輔以科學的sql編寫模式、巧妙的緩存翻譯集成、極致的分頁優化以及針對大規模數據下的分庫分表
  • MySQL如何定位慢sql？
    MySQL「慢SQL」定位資料庫調優我個人覺得必須要明白兩件事1.定位問題（你得知道問題出在哪裡，要不然從哪裡調優呢）2.解決問題（這個沒有基本的方法來處理，因為不同的問題處理的方式方法不一樣，得從實踐中不斷的探索，如sql調優，配置優化，硬體升級等等）
  • 聊聊Mysql——慢sql優化方法論
    總結了一些解決慢sql的方法，供參考。一、慢sql優化訂閱每日慢日誌，優先解決調用次數多的慢sql，因慢sql優化的知識點非常多，只列舉幾個容易忽視的地方。注意：1、數據量不同，查詢條件不同，sql使用的索引可能是不一樣的，要構造多種查詢條件去測試。2、避免所有欄位都返回，儘量使用覆蓋索引，解決慢sql問題，終歸是與庫的磁碟IO、CPU做抗爭。
  • Mybaits中Like 的使用方式以及一些注意點
    --有sql注入問題--> <select id="findUserByLikeName1" parameterType="java.lang.String" resultMap="user"> select * from t_user where name like '%${name}%' </select>這種會有sql注入的問題，需要明白在 Mybatis中 $
  • sqltoy-orm第一講:什麼才是最NB的分頁！
    t2 on t1.ORGAN_ID=t2.ORGAN_IDwhere t1.name like &39; and t1.DUTY_DATE>=&39; and t1.DUTY_DATE<=&39;我們再來優化，我們發現查詢條件完全落在了員工信息表上：通過 @fast
  • mysql┃多個角度說明sql優化,讓你吊打面試官!
    sql優化，最近moon一直在寫關於mysql的文章，包括之前寫的索引相關，其實也都是為了這篇文章做個鋪墊，所以你懂了嗎，今天我將從表結構、索引、查詢語句、分庫分表這四個維度來和大家聊聊，在工作中，怎麼進行sql優化？
  • 乾貨總結-全面解析SQL優化
    ③查詢優化基本思路：1、有大炮，就別用手槍。查詢要走索引2、溺水三千隻取一瓢，不要select *3、資料庫是用來存的，不是用來算的，查就查，不要算1工具（以MySQL為例）：1、用Explain查看 SQL
  • sqltoy-orm4.16.1發版，深度對比mybatis
    致謝：1、首先要特別感謝大家的積極反饋，提出了非常好的意見，比如通過sqlId組合dialect實現sql跨資料庫、@loop循環組織sql 等等，很多東西雖然是極端場景，但充實了sqltoy面對極端場景的應對能力！
  • 比mybatis 強大優雅的 sqltoy-orm-4.10.5 發版了
    /sqltoy/#/更新內容：1、緩存翻譯對應的緩存更新機制增加增量更新2、查詢結果計算增加環比計算，請參見sqltoy-showcase下的QueryCaseTest類sqltoy的代表性特性展示：1、最優雅的sql編寫模式 select * from sqltoy_device_order_info t <
  • 你真的了解mysql資料庫對like語句處理過程嗎
    用過sql的同學基本都會過like，但是大家對like了解多少，很多同學可能認知在like條件，如果第一個字符為通配符，sql語句就不會走索引，如果不為通配符，sql語句就會走索引，真相真的是這樣的嗎，我用實際測試案例來說明。
  • sqltoy-orm-4.17.2 發版,部分功能優化
    開源地址：更新內容1、優化update(entity,forceUpdateFields) 強制屬性優先於統一欄位處理