優化sqllike
⑴ sql語句查詢，多欄位like模糊查詢優化
1、多欄位like模糊查詢優化：
最常見的寫法：
where a like '%xx%' or b like '%xx%' or c like '%xx%';
這種寫法查詢效率低，經過調查，下面的方法可以替代，並且效率高：
2、如果like的關鍵字相同：
where instr(nvl(a, '')||nvl(b,'')||nvl(c,''), 'xx') > 0
把要模糊查詢的欄位先拼接起來，拼接時需要把null轉成『』，否則只要有一個欄位值是空，整個拼接的字元串都成空了， 然後用instr 函數去過濾；
3、如果like的關鍵字不同：
where instr(a, 'xx') > 0 or instr(b, 'yy') > 0 or instr(c, 'zz') > 0
經過測試，這兩種方法都比like效率要高；
⑵ sybase資料庫的「like」用法是什麼
想在SQL LIKE里查詢有下劃線'_'或是'%'等值的記錄，直接寫成like 'XXX_XX'，則會把'_'當成是like的通配符。
SQL里提供了 escape子句來處理這種情況，escape可以指定like中使用的轉義符是什麼，而在轉義符後的字元將被當成原始字元，這和C里的''很像，但是escape要求自定義一個轉義符，而不是指定了'』字元。
⑶ 一條sql:如何優化 where name like '%ab%' or name like
方法一: 將or條件變為3個查詢，然後用union將3個查詢的結果集合並起來(or會降低查詢效率)。
方法二: 使用類似正則表達式的匹配將3個like合並, name like '%[ab|cd|ef]%'。注意，這個需要資料庫支持。
⑷ Sql優化-多like模糊查詢及根據時間排序
2020-04-21
記錄一次sql優化記錄：
環境：用的mysql版本 select Version();
優化過程：
用的是兩張表聯查，四個條件like查詢 ，根據時間排序降序
其中A，B表沒有大欄位，A表20萬多數據，B表50萬多條數據。語句如下：
EXPLAIN
SELECT A.bondId,A.sname,A.cname,A.secuCode,A. ISSUER,A.guarantor,B.underwriter AS infoSource
FROM A
LEFT JOIN B ON B.bondId = A.bondId
WHERE B.agentType = 1
AND B.underwriter = '有限公司'
AND A.startDate <= '2020-04-21 18:02:10'
AND A.endDate >= '2020-04-21 18:02:10'
AND (
A.cname LIKE '%%' OR A.sname LIKE '%%' OR A.secuCode LIKE '%%'
OR A. ISSUER LIKE '%%'OR A.guarantor LIKE '%%')
AND A.isValid = 1
ORDER BY A.startDate DESC
LIMIT 0, 20
這是2個表都沒有加索引的情況，從explain來看結果非常糟糕，都是全表掃描，並且產生臨時表同時有文件排序，效率肯定非常低。
首先嘗試在B表上建立一個聯合索引
可以考慮從關聯欄位及where條件欄位考慮（bondId, underwriter, agentType）
建一個聯合索引，試試。
ALTER TABLE B ADD INDEX bua_index(bondId, underwriter, agentType)
再explain看：
可以看到B表用到了我們剛剛建的聯合索引，並且額外信息是Using index ，type是ref級別的，效果比較理想，再來看A表。
Where條件中有多個like，這種情況下一般索引都是不可用的，所以必須用覆蓋索引解決，
由於又根據startDate排序，所以嘗試根據如下欄位建立聯合索引，同時查詢的欄位就是索引中的欄位（startDate, endDate,cname, sname, secuCode, issuer, guarantor）
ALTER TABLE A ADD INDEX index_scssig(startDate, endDate,cname, sname, secuCode, issuer, guarantor)
再次explain看看效果：
這樣乍看上去A表也用到了剛剛建的聯合索引，並且type是range級別雖然比ref差點，按理說應該也還可以，但是我執行sql語句，效率還是非常差，查詢耗時達到8s，並且偶爾還不止這個時間
究其原因，雖然使用了索引，但是extra裡面是Using index condition&Using where
回表操作了，我在想如果將extra優化成Using index效率肯定沒問題
故再進一步優化，還是從索引入手
在聯合索引上添加2個欄位isValid, bondId 再試試
ALTER TABLE A ADD INDEX index_scssig(isvalid,startDate, endDate,cname, sname, secuCode, issuer, guarantor,bondId)
再次explain:
這個結果就是我想要的，然後執行sql看看效率：
已經提升了很多了，但是我試了別的查詢條件偶爾時間會到3，4s,懷疑和自己的機器有關
在這這種多個like的or查詢mysql本身並不擅長，無奈坑爹的需要需要這樣，可能效率並不是非常的高，優化成這樣可以接受了。
最近對以前項目的慢查詢進行sql調優，感覺性能的下降往往還是sql語句及索引的建立的問題，explain是很有幫助，正確優化還是能極大提升效率的。