⑴ 關於sql查詢代碼優化問題
1對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
3.應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
4.應盡量避免在 where 子句中使用 or 來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num=10 or num=20
可以這樣查詢：
select id from t where num=10
union all
select id from t where num=20
5.in 和 not in 也要慎用，否則會導致全表掃描，如：
select id from t where num in(1,2,3)
對於連續的數值，能用 between 就不要用 in 了：
select id from t where num between 1 and 3
6.下面的查詢也將導致全表掃描：
select id from t where name like '«c%'
若要提高效率，可以考慮全文檢索。
7.如果在 where 子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變數，但優化程序不能將訪問計劃的選擇推遲到運行時;它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變數的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：
select id可以改為強制查詢使用索引：
select id from t with(index(索引名)) where num=@num
8.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where num/2=100
應改為:
select id from t where num=100*2
9.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
select id from t where substring(name,1,3)='abc'--name以abc開頭的id
select id from t where datediff(day,createdate,'2005-11-30')=0--『2005-11-30』生成的id
應改為:
select id from t where name like 'abc%'
select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'
10.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
11.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致
12.不要寫一些沒有意義的查詢，如需要生成一個空表結構：
select col1,col2 into #t from t where 1=0
這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：
create table #t(...)
13.很多時候用 exists 代替 in 是一個好的選擇：
select num from a where num in(selectnum from b)
用下面的語句替換：
select num from a where exists(select 1 from b where num=a.num)
14.並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有欄位sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。
15.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。
16.應盡可能的避免更新 clustered 索引數據列，因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那麼需要考慮是否應將該索引建為 clustered 索引。
17.盡量使用數字型欄位，若只含數值信息的欄位盡量不要設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。
18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。
19.任何地方都不要使用 select * from t ，用具體的欄位列表代替「*」，不要返回用不到的任何欄位。
20.盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限(只有主鍵索引)。
21.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。
22.臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。
23.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度;如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。
24.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。
25.盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那麼就應該考慮改寫。
26.使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。
27.與臨時表一樣，游標並不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括「合計」的常式通常要比使用游標執行的速度快。如果開發時間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。
28.在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。
29.盡量避免大事務操作，提高系統並發能力。
30.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。
⑵ 資料庫表數據量大怎麼優化查詢速度
下面以關系資料庫系統Informix為例，介紹改善用戶查詢計劃的方法。
1．合理使用索引
索引是資料庫中重要的數據結構，它的根本目的就是為了提高查詢效率。現在大多數的資料庫產品都採用IBM最先提出的ISAM索引結構。索引的使用要恰到好處，其使用原則如下：
●在經常進行連接，但是沒有指定為外鍵的列上建立索引，而不經常連接的欄位則由優化器自動生成索引。
●在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引。
●在條件表達式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。比如在雇員表的「性別」列上只有「男」與「女」兩個不同值，因此就無必要建立索引。如果建立索引不但不會提高查詢效率，反而會嚴重降低更新速度。
●如果待排序的列有多個，可以在這些列上建立復合索引（compound index）。
●使用系統工具。如Informix資料庫有一個tbcheck工具，可以在可疑的索引上進行檢查。在一些資料庫伺服器上，索引可能失效或者因為頻繁操作而使得讀取效率降低，如果一個使用索引的查詢不明不白地慢下來，可以試著用tbcheck工具檢查索引的完整性，必要時進行修復。另外，當資料庫表更新大量數據後，刪除並重建索引可以提高查詢速度。
2．避免或簡化排序
應當簡化或避免對大型表進行重復的排序。當能夠利用索引自動以適當的次序產生輸出時，優化器就避免了排序的步驟。以下是一些影響因素：
●索引中不包括一個或幾個待排序的列；
●group by或order by子句中列的次序與索引的次序不一樣；
●排序的列來自不同的表。
為了避免不必要的排序，就要正確地增建索引，合理地合並資料庫表（盡管有時可能影響表的規范化，但相對於效率的提高是值得的）。如果排序不可避免，那麼應當試圖簡化它，如縮小排序的列的范圍等。
3．消除對大型錶行數據的順序存取
在嵌套查詢中，對表的順序存取對查詢效率可能產生致命的影響。比如採用順序存取策略，一個嵌套3層的查詢，如果每層都查詢1000行，那麼這個查詢就要查詢10億行數據。避免這種情況的主要方法就是對連接的列進行索引。例如，兩個表：學生表（學號、姓名、年齡……）和選課表（學號、課程號、成績）。如果兩個表要做連接，就要在「學號」這個連接欄位上建立索引。
還可以使用並集來避免順序存取。盡管在所有的檢查列上都有索引，但某些形式的where子句強迫優化器使用順序存取。下面的查詢將強迫對orders表執行順序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
雖然在customer_num和order_num上建有索引，但是在上面的語句中優化器還是使用順序存取路徑掃描整個表。因為這個語句要檢索的是分離的行的集合，所以應該改為如下語句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
這樣就能利用索引路徑處理查詢。
4．避免相關子查詢
一個列的標簽同時在主查詢和where子句中的查詢中出現，那麼很可能當主查詢中的列值改變之後，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。如果子查詢不可避免，那麼要在子查詢中過濾掉盡可能多的行。
5．避免困難的正規表達式
MATCHES和LIKE關鍵字支持通配符匹配，技術上叫正規表達式。但這種匹配特別耗費時間。例如：SELECT ＊ FROM customer WHERE zipcode LIKE 「98_ _ _」
即使在zipcode欄位上建立了索引，在這種情況下也還是採用順序掃描的方式。如果把語句改為SELECT ＊ FROM customer WHERE zipcode >「98000」，在執行查詢時就會利用索引來查詢，顯然會大大提高速度。
另外，還要避免非開始的子串。例如語句：SELECT ＊ FROM customer WHERE zipcode[2，3]>「80」，在where子句中採用了非開始子串，因而這個語句也不會使用索引。
6．使用臨時表加速查詢
把表的一個子集進行排序並創建臨時表，有時能加速查詢。它有助於避免多重排序操作，而且在其他方面還能簡化優化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>「98000」
ORDER BY cust.name
如果這個查詢要被執行多次而不止一次，可以把所有未付款的客戶找出來放在一個臨時文件中，並按客戶的名字進行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然後以下面的方式在臨時表中查詢：
SELECT ＊ FROM cust_with_balance
WHERE postcode>「98000」
臨時表中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁碟I/O，所以查詢工作量可以得到大幅減少。
注意：臨時表創建後不會反映主表的修改。在主表中數據頻繁修改的情況下，注意不要丟失數據。
7．用排序來取代非順序存取
非順序磁碟存取是最慢的操作，表現在磁碟存取臂的來回移動。SQL語句隱藏了這一情況，使得我們在寫應用程序時很容易寫出要求存取大量非順序頁的查詢。
有些時候，用資料庫的排序能力來替代非順序的存取能改進查詢。
⑶ 查詢條件相同大量sql執行該怎樣優化
：1. SQL優化的原則是：將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量。 調整不良SQL通常可以從以下幾點切入： ? 檢查不良的SQL，考慮其寫法是否還有可優化內容 ?
⑷ 一條sql執行過長的時間，你如何優化，從哪些方面
1、查看sql是否涉及多表的聯表或者子查詢，如果有，看是否能進行業務拆分，相關欄位冗餘或者合並成臨時表（業務和演算法的優化）
2、涉及鏈表的查詢，是否能進行分表查詢，單表查詢之後的結果進行欄位整合
3、如果以上兩種都不能操作，非要鏈表查詢，那麼考慮對相對應的查詢條件做索引。加快查詢速度
4、針對數量大的表進行歷史表分離（如交易流水表）
5、資料庫主從分離，讀寫分離，降低讀寫針對同一表同時的壓力，至於主從同步，mysql有自帶的binlog實現 主從同步
6、explain分析sql語句，查看執行計劃，分析索引是否用上，分析掃描行數等等
7、查看mysql執行日誌，看看是否有其他方面的問題
個人理解：從根本上來說，查詢慢是佔用mysql內存比較多，那麼可以從這方面去酌手考慮
⑸ mysql資料庫大量查詢次數如何優化
MySQL 8.0.16 已經發布，它像往常一樣增強了組復制 Group Replication 功能。
這篇文章介紹了 MySQL 8.0.16 為 Group Replication 帶來的新功能：
Message fragmentation（信息碎片化）。
背景
Group Replication 目前使用 XCom（一種組通信引擎），特點：原子性，組員狀態檢測等。每個成員的組復制插件先將信息轉發到本地 XCom，再由 XCom 最終以相同的順序將信息傳遞給每個組成員的 Group Replication 插件。
XCom 由單線程實現。當一些成員廣播信息過大時，XCom 線程必須花費更多的時間來處理那個大信息。如果成員的 XCom 線程忙於處理大信息的時間過長，它可能會去查看其他成員的 XCom 實例。例如，忙碌的成員失效。如果是這樣，該組可以從該組中驅逐忙碌的成員。
MySQL 8.0.13 新增group_replication_member_expel_timeout系統變數，您可以通過它來調整將成員從組中驅逐的時間。例如，懷疑成員失敗，但成員實際上忙於處理大信息，給成員足夠的時間來完成處理。在這種情況下，是否為成員增加驅逐超時的設置是一種權衡。有可能等了很久，該成員實際真的失效了。
Message fragmentation（信息碎片化）
MySQL 8.0.16 的 Group Replication 插件新增用來處理大信息的功能：信息碎片化。
簡而言之，您可以為成員的廣播信息指定最大值。超過最大值的信息將分段為較小的塊傳播。
您可以使用 group_replication_communication_max_message_size系統變數指定允許的信息最大值（默認值為10 MiB）。
示例
讓我們用一個例子來解釋新功能。圖1顯示了當綠色成員向組廣播信息時，新功能是如何處理的。
圖1 對傳出信息進行分段
1. 如果信息大小超過用戶允許的最大值（group_replication_communication_max_message_size），則該成員會將信息分段為不超過最大值的塊。
2. 該成員將每個塊廣播到該組，即將每個塊單獨轉發到XCom。
XCom 最終將這些塊提供給組成員。下面三張圖展示出了中間綠色成員發送大信息時工作的新特徵。
圖2a 重新組合傳入的信息：第一個片段
3. 成員得出結論，傳入的信息實際上是一個更大信息的片段。
4. 成員緩沖傳入的片段，因為他們認為片段是仍然不完整的信息的一部分。（片段包含必要的元數據以達到這個結論。）
圖2b 重新組合傳入的信息：第二個片段
5. 見上面的第3步。
6. 見上面的第4步。
圖2c 重新組合傳入的信息：最後一個片段
7. 成員得出結論，傳入的信息實際上是一個更大信息的片段。
8. 成員得出結論，傳入的片段是最後一個缺失的塊，重新組合原始信息，然後對其進行處理，傳輸完畢。
結論
MySQL 8.0.16 已經發布後，組復制現在可以確保組內交換的信息大小不超過用戶定義的閾值。這可以防止組內誤判而驅逐成員。
⑹ mysql中怎樣對大批量級的數據查詢進行優化
在我們使用MySQL資料庫時，比較常用也是查詢，包括基本查詢，關聯查詢，條件查詢等等，對於同一個操作，SQL語句的實現有很多種寫法，但是不同的寫法查詢的性能可能會有很大的差異。這里主要介紹下select查詢優化的要點。
1. 使用慢查詢日誌去發現慢查詢。
2. 使用執行計劃去判斷查詢是否正常運行。
3. 總是去測試你的查詢看看是否他們運行在最佳狀態下 –久而久之性能總會變化。
4. 避免在整個表上使用count(*),它可能鎖住整張表。
5. 使查詢保持一致以便後續相似的查詢可以使用查詢緩存。
6. 在適當的情形下使用GROUP BY而不是DISTINCT。
7. 在WHERE, GROUP BY和ORDER BY子句中使用有索引的列。
8. 保持索引簡單,不在多個索引中包含同一個列。
9. 有時候MySQL會使用錯誤的索引,對於這種情況使用USE INDEX。
10. 檢查使用SQL_MODE=STRICT的問題。
11.對於記錄數小於5的索引欄位，在UNION的時候使用LIMIT不是是用OR.
12. 為了 避免在更新前SELECT，使用INSERT ON DUPLICATE KEY或者INSERT IGNORE ,不要用UPDATE去實現。
3. 不要使用 MAX,使用索引欄位和ORDER BY子句。
14. 避免使用ORDER BY RAND().
15. LIMIT M，N實際上可以減緩查詢在某些情況下，有節制地使用。
16. 在WHERE子句中使用UNION代替子查詢。
17. 對於UPDATES（更新），使用 SHARE MODE（共享模式），以防止獨占鎖。
18. 在重新啟動的MySQL，記得來溫暖你的資料庫，以確保您的數據在內存和查詢速度快。
19. 使用DROP TABLE，CREATE TABLE DELETE FROM從表中刪除所有數據。
20. 最小化的數據在查詢你需要的數據，使用*消耗大量的時間。
21. 考慮持久連接，而不是多個連接，以減少開銷。
22. 基準查詢，包括使用伺服器上的負載，有時一個簡單的查詢可以影響其他查詢。
23. 當負載增加您的伺服器上，使用SHOW PROCESSLIST查看慢的和有問題的查詢。
24. 在開發環境中產生的鏡像數據中 測試的所有可疑的查詢。
來源：PHP程序員雷雪松的博客
⑺ 查詢資料庫時數據量特別大，咋樣用 sql優化
1、優化SQL語句，使用Where限定查詢的數據范圍
2、建立相關欄位的索引，避免查詢時進行全表掃描
3、多數據表連接時，注意連接的主從表位置，避免小表Join大表
⑻ 如何進行SQL性能優化
這里分享下mysql優化的幾種方法。
1、首先在打開的軟體中，需要分別為每一個表創建 InnoDB FILE的文件。
⑼ sql查詢優化的幾種方法
1、創建索引；
2、採用分區表；
3、盡量採用join進行多表關聯查詢；
4、能用exists就不用in;
5、盡量採用覆蓋索引。
⑽ sql資料庫 大數據量查詢 優化!!
我搞過一個銷售管理的網站,一些客戶的瀏覽記錄也很多.
後來我們用了按類型分表的方法.把一個很長的表分成了7個表,然後建立視圖來把他們弄一起,當然SQL優化是少不了的,盡量減少join和left的次數,適當建立索引.
你朋友圈的話,建議你用Ajax,動態刷新,那麼是否考慮在這一次刷新頁面的時候在後台先准備好下一次的查詢數據呢.因為這個是一段一段的,顯示一段,然後准備下一段.
PS:我這只是個人建議,希望能幫到你