『壹』 核銷明細查詢in條件過多導致sql超時優化
現狀：查詢條件中in條件包含了400+門店的條件 且是返回全表欄位，需要排序+分頁查詢 優化：（前提，做數據歸檔） 1.將大量門店查詢拆分成 50個門店一次查詢 ，且只查詢主鍵id，通過分次查詢將查詢到的數據匯總（此時數據可能會有上萬 但只包含主鍵id） 2.根據分頁條件去其中符合條件的主鍵id （此時安分頁篩選出來的數據一般10-30個） 3.根據篩選出的主鍵id通過in條件查詢符合條件的數據返回『貳』 mysql多條件查詢的優化
如果對查詢要求高，可使用myisam.
幾個優化建議：
（1）適當的建立欄位索引。
（2）注意sql條件的順序，把能夠排除掉大量數據的條件寫在前面。
『叄』 sql調優的幾種方式
你好，
SQL優化的一些方法
1.對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描。
3.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
4.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描。
5.in 和 not in 也要慎用，否則會導致全表掃描，
6.下面的查詢也將導致全表掃描：
select id from t where name like '%abc%'
7.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。
8.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。
9.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
10.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
『肆』 mssql sql語句多條件查詢優化問題。
很簡單，最終查詢的結果是新聞，所以新聞表是你的主要查詢表
企業、品牌、媒體這三個都是條件
我認為，你的新聞表中應該有兩種形式，
一是同時包括三種條件，包括企業、品牌、媒體代碼、新聞標題、內容等關鍵欄位
查詢的時候sql語句非常簡單，就是select 新聞 from 新聞表 where 企業 in （條件）or 品牌 in （條件）or 媒體 in （條件）
這樣一個不好就是新聞庫過大，但是因為沒有做表關聯查詢，所以速度非常快
二是僅包括一種條件，新聞分別在3個表中保存
查詢的時候需要union聯合查詢，這樣的優勢是每個表都相對較小，如果用戶只查詢一個條件，那查詢工作量會非常低。
select 新聞 from 新聞表1 where 企業 in （條件）
union select 新聞 from 新聞表2 where 品牌 in （條件）
union select 新聞 from 新聞表3 where 媒體 in （條件）
好了，你會發現，通過這兩種sql，實際上主要工作集中在前台界面的開發上，需要能根據用戶的選擇有效地拼寫sql語句。
至於用戶許可權，這個是許可權表的事情，與查詢結果的速度無關，只涉及到能生成哪些條件
不明白再問我
『伍』 SQL語句中的多個OR該怎麼來優化
與或非是邏輯判斷的必須，如果真的需要很多or來判斷，那麼誰也沒有辦法。
一般優化or的辦法是，減少or，也就是減少判斷條件。這個不僅僅是資料庫的問題，需要從業務等多方面來考慮。
比如，業務可以減少一個or，那麼這就是最好的優化方式。
如果幾個or欄位都有索引，那麼可以考慮分開查詢，這樣能走索引，因為or不走索引。也算優化。
縮小查詢范圍也算，雖然還是or，還是那麼多條件，但是其他條件卻可以，讓數據量從10w，變為5千，這也是優化。
至於其他的方法，什麼換個寫法等等，大多數都是扯淡，沒什麼實際意義。
『陸』 sql多條件查詢，如何高效組合多個條件
多條件查詢還是不定條件查詢？
多條件查詢，要注意OR的運用，同一欄位多個OR的情況會影響效率的。
另外主要的固定條件，比如單號，集團號等建立索引。在其基礎上多用加幾個AND都沒有問題。
子查詢、函數等不合算做查詢條件。這個也會根據數量量大小而影響效率。
『柒』 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是很有幫助，正確優化還是能極大提升效率的。
『捌』 如何進行SQL性能優化
這里分享下mysql優化的幾種方法。
1、首先在打開的軟體中，需要分別為每一個表創建 InnoDB FILE的文件。
『玖』 sql 提高多條件查詢效率
可建立一個類別表：CREATE TABLE 類別表（產品編號 char(1)，類別 char(20)）；
再與類別表查詢；或在原表增加此2個欄位。
另外：插入臨時表(以substring(產品編號,1,1)為組)
select distict substring(產品編號,1,1), RTRIM(left(CONVERT(varchar(5), 日期, 0),2)) + ''月'' as 月份,CONVERT(varchar(100),日期,23) as 日期,單號,發貨人,收貨人, sum(abs(數量))as 數量 ,單價, sum(金額) as 金額 from '+ @ckgs +' where substring(產品編號,1,1) like '''+ @cpfl +''' and 單據分類 like '''+@djfl+''' and 產品名稱 like '''+@cpmc+''' and 發貨人 like '''+@ffr +''' and 收貨人 like ''' +@sfr+''' group by 日期,單號,substring(產品編號,1,1), 發貨人,收貨人,單價 into temp;
再查詢temp表。