『壹』 2020-10-11：一條sql語句執行時間過長，應該如何優化從哪些方面進行優化
改進資料庫sql語句進行優化的理由 應用程序之優化通常可分為兩個方面：源代碼之優化和sql語句之優化。源代碼之優化在時間成本和風險上代價很高；另一方面，源代碼之優化對資料庫系統性能之提升收效有限。 優化之理由 1)sql語句是對資料庫(數據)進行操作之惟一途徑； 2)sql語句消耗了70%~90%之資料庫資源； 3)sql語句獨立於程序設計邏輯，相對於對程序源代碼之優化，對sql語句之優化在時間成本和風險上之代價都很低； 4)sql語句可以有不同之寫法； 5)sql語句易學，難精通。 優化技術之發展 第一代之sql優化工具是執行計劃分析工具。這類之工具對輸入之sql語句從資料庫提取執行計劃，並解釋執行計劃中關鍵字之含義；第二代之sql優化工具只能提供增加索引之建議，它通過對輸入之sql語句之執行計劃之分析來產生是否要增加索引之建議。該類工具存在著致命之缺點——只分析了一條sql語句就得出增加某個索引之結論，根本不理會(實際上也無法評估到)增加之索引對整體資料庫系統性能之影響。其破壞性在於： 1、不理會增加之索引對其他增、刪、改sql語句之負面影響； 2、沒有考慮增加之索引可能導致資料庫判斷失誤； 3、對由於增加索引引起之資料庫系統負擔忽略不計。 同時，這些工具由於技術水平之限制存在著以下缺點： 1、無法保證建議或改寫之正確性； 2、無法進行重寫，僅僅提供了建議或有限程度之改寫，重寫工作還是需要人工完成，優化工作所需之時間和工作量同人工進行優化差不多； 3、改寫之規則和hints有限，難以處理復雜之sql語句； 4、必須人手逐條進行測試。 這類工具曾經盛極一時，直到人工智慧自動sql優化之出現。
『貳』 從哪些方面，sql語句性能如何分析
一段SQL代碼寫好以後，可以通過查看SQL的執行計劃，初步預測該SQL在運行時的性能好壞，尤其是在發現某個SQL語句的效率較差時，我們可以通過查看執行計劃，分析出該SQL代碼的問題所在。
1、 打開熟悉的查看工具：PL/SQL Developer。
在PL/SQL Developer中寫好一段SQL代碼後，按F5，PL/SQL Developer會自動打開執行計劃窗口，顯示該SQL的執行計劃。
2、 查看總COST，獲得資源耗費的總體印象
一般而言，執行計劃第一行所對應的COST(即成本耗費)值，反應了運行這段SQL的總體估計成本，單看這個總成本沒有實際意義，但可以拿它與相同邏輯不同執行計劃的SQL的總體COST進行比較，通常COST低的執行計劃要好一些。
3、 按照從左至右，從上至下的方法，了解執行計劃的執行步驟
執行計劃按照層次逐步縮進，從左至右看，縮進最多的那一步，最先執行，如果縮進量相同，則按照從上而下的方法判斷執行順序，可粗略認為上面的步驟優先執行。每一個執行步驟都有對應的COST,可從單步COST的高低，以及單步的估計結果集（對應ROWS/基數），來分析表的訪問方式，連接順序以及連接方式是否合理。
4、 分析表的訪問方式
表的訪問方式主要是兩種：全表掃描（TABLE ACCESS FULL）和索引掃描(INDEX SCAN)，如果表上存在選擇性很好的索引，卻走了全表掃描，而且是大表的全表掃描，就說明表的訪問方式可能存在問題；若大表上沒有合適的索引而走了全表掃描，就需要分析能否建立索引，或者是否能選擇更合適的表連接方式和連接順序以提高效率。
5、 分析表的連接方式和連接順序
表的連接順序：就是以哪張表作為驅動表來連接其他表的先後訪問順序。
表的連接方式：簡單來講，就是兩個表獲得滿足條件的數據時的連接過程。主要有三種表連接方式，嵌套循環（NESTED LOOPS）、哈希連接（HASH JOIN）和排序-合並連接（SORT MERGE JOIN）。我們常見得是嵌套循環和哈希連接。
嵌套循環：最適用也是最簡單的連接方式。類似於用兩層循環處理兩個游標，外層游標稱作驅動表，Oracle檢索驅動表的數據，一條一條的代入內層游標，查找滿足WHERE條件的所有數據，因此內層游標表中可用索引的選擇性越好，嵌套循環連接的性能就越高。
哈希連接：先將驅動表的數據按照條件欄位以散列的方式放入內存，然後在內存中匹配滿足條件的行。哈希連接需要有合適的內存，而且必須在CBO優化模式下，連接兩表的WHERE條件有等號的情況下才可以使用。哈希連接在表的數據量較大，表中沒有合適的索引可用時比嵌套循環的效率要高。
『叄』 資料庫的性能優化有哪些
在資料庫優化上有兩個主要方面：
安全：數據可持續性。
性能：數據的高性能訪問。
優化的范圍有哪些
存儲、主機和操作系統方面：
主機架構穩定性
I/O 規劃及配置
Swap 交換分區
OS 內核參數和網路問題
應用程序方面：
應用程序穩定性
SQL 語句性能
串列訪問資源
性能欠佳會話管理
這個應用適不適合用 MySQL
資料庫優化方面：
內存
資料庫結構(物理&邏輯)
實例配置
說明：不管是設計系統、定位問題還是優化，都可以按照這個順序執行。
資料庫優化維度有如下四個：
硬體
系統配置
資料庫表結構
SQL 及索引
優化選擇：
優化成本：硬體>系統配置>資料庫表結構>SQL 及索引。
優化效果：硬體<系統配置<資料庫表結構
『肆』 sql語句性能如何優化
如何加快查詢速度?
1、升級硬體
2、根據查詢條件,建立索引,優化索引、優化訪問方式，限制結果集的數據量。
3、擴大伺服器的內存
4、增加伺服器CPU個數
5、對於大的資料庫不要設置資料庫自動增長，它會降低伺服器的性能
6、在查詢Select語句中用Where字句限制返回的行數,避免表掃描,如果返回不必要的數據，浪費了伺服器的I/O資源，加重了網路的負擔降低性能。如果表很大，在表掃描的期間將表鎖住，禁止其他的聯接訪問表,後果嚴重。
7、查詢時不要返回不需要的行、列
8、用select
top
100
/
10
Percent
來限制用戶返回的行數或者SET
ROWCOUNT來限制操作的行
9、在IN後面值的列表中，將出現最頻繁的值放在最前面，出現得最少的放在最後面，減少判斷的次數
10、一般在GROUP
BY
個HAVING字句之前就能剔除多餘的行，所以盡量不要用它們來做剔除行的工作。他們的執行順序應該如下最優：
select的Where字句選擇所有合適的行，Group
By用來分組個統計行，Having字句用來剔除多餘的分組。這樣Group
By
個Having的開銷小，查詢快.對於大的數據行進行分組和Having十分消耗資源。如果Group
BY的目的不包括計算，只是分組，那麼用Distinct更快
11、一次更新多條記錄比分多次更新每次一條快,就是說批處理好
『伍』 如何對資料庫性能進行優化
1.資料庫I/O方面硬體性能
最有可能影響性能的是磁碟和網路吞吐量。解決辦法：
擴大虛擬內存，並保證有足夠可以擴充的空間
把資料庫伺服器上的不必要服務關閉掉
把SQL資料庫伺服器的吞吐量調為最大
若對該表的查詢頻率比較高，則建立索引。
分區（如MySQL，按時間分區）
盡量使用固定長度欄位和限制欄位長度（如 varchar(10)）優勢：
降低物理存儲空間
提高資料庫處理速度
附帶校驗資料庫是否合法功能優化sql語句，減少比較次數
限制返回條目數(mysql中使用limit)
盡可能的少創造對象
合理擺正系統設計的位置。大量數據操作，和少量數據操作一定是分開的。
合理利用內存，有的數據要緩存。讓數據流起來，而不是全部讀到內存再處理，而是邊讀取邊處理。
2.調整資料庫
3.使用存儲過程
應用程序的實現過程中，能夠採用存儲過程實現的對資料庫的操作盡量通過存儲過程來實現。
因為存儲過程是存放在資料庫伺服器上的一次性被設計、編碼、測試，並被再次使用，需要執行該任務的應用可以簡單地執行存儲過程，並且只返回結果集或者數值。
這樣不僅可以使程序模塊化，同時提高響應速度，減少網路流量，並且通過輸入參數接受輸入，使得在應用中完成邏輯的一致性實現。
4.SQL語句方面
建立查詢條件索引僅僅是提高速度的前提條件，響應速度的提高還依賴於對索引的使用。不良的SQL往往來自於不恰當的索引設計、不充份的連接條件和不可優化的where子句。
5.Java方面
『陸』 SQL優化的幾個方面
① 為查詢緩存優化查詢
② EXPLAIN 我們的SELECT查詢(可以查看執行的行數)
③ 當只要一行數據時使用LIMIT 1
④ 為搜索欄位建立索引
⑤ 在Join表的時候使用相當類型的列，並將其索引
⑥ 千萬不要 ORDER BY RAND ()
⑦ 避免SELECT *
⑧ 永遠為每張表設置一個ID
⑨ 可以使用ENUM 而不要VARCHAR
⑩ 盡可能的使用NOT NULL
⑪ 固定長度的表會更快
⑫ 垂直分割
⑬ 拆分打的DELETE或INSERT語句
⑭ 越小的列會越快
⑮ 選擇正確的存儲引擎
⑯ 小心 "永久鏈接"
『柒』 一條sql執行過長的時間，你如何優化，從哪些方面
1、查看sql是否涉及多表的聯表或者子查詢，如果有，看是否能進行業務拆分，相關欄位冗餘或者合並成臨時表（業務和演算法的優化）
2、涉及鏈表的查詢，是否能進行分表查詢，單表查詢之後的結果進行欄位整合
3、如果以上兩種都不能操作，非要鏈表查詢，那麼考慮對相對應的查詢條件做索引。加快查詢速度
4、針對數量大的表進行歷史表分離（如交易流水表）
5、資料庫主從分離，讀寫分離，降低讀寫針對同一表同時的壓力，至於主從同步，mysql有自帶的binlog實現 主從同步
6、explain分析sql語句，查看執行計劃，分析索引是否用上，分析掃描行數等等
7、查看mysql執行日誌，看看是否有其他方面的問題
個人理解：從根本上來說，查詢慢是佔用mysql內存比較多，那麼可以從這方面去酌手考慮
『捌』 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.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
『玖』 請簡述項目中優化sql語句執行效率的方法,從哪些方面,sql語句性能如何分析
1. SQL優化的原則是：將一次操作需要讀取的BLOCK數減到最低,即在最短的時間達到最大的數據吞吐量。
調整不良SQL通常可以從以下幾點切入：
? 檢查不良的SQL，考慮其寫法是否還有可優化內容
? 檢查子查詢 考慮SQL子查詢是否可以用簡單連接的方式進行重新書寫
? 檢查優化索引的使用
? 考慮資料庫的優化器
2. 避免出現SELECT * FROM table 語句，要明確查出的欄位。
3. 在一個SQL語句中，如果一個where條件過濾的資料庫記錄越多，定位越准確，則該where條件越應該前移。
4. 查詢時盡可能使用索引覆蓋。即對SELECT的欄位建立復合索引，這樣查詢時只進行索引掃描，不讀取數據塊。
5. 在判斷有無符合條件的記錄時建議不要用SELECT COUNT （*）和select top 1 語句。
6. 使用內層限定原則，在拼寫SQL語句時，將查詢條件分解、分類，並盡量在SQL語句的最里層進行限定，以減少數據的處理量。
7. 應絕對避免在order by子句中使用表達式。
8. 如果需要從關聯表讀數據，關聯的表一般不要超過7個。
9. 小心使用 IN 和 OR，需要注意In集合中的數據量。建議集合中的數據不超過200個。
10. <> 用 < 、 > 代替，>用>=代替，<用<=代替，這樣可以有效的利用索引。
11. 在查詢時盡量減少對多餘數據的讀取包括多餘的列與多餘的行。
12. 對於復合索引要注意，例如在建立復合索引時列的順序是F1，F2，F3，則在where或order by子句中這些欄位出現的順序要與建立索引時的欄位順序一致，且必須包含第一列。只能是F1或F1，F2或F1，F2，F3。否則不會用到該索引。
13. 多表關聯查詢時，寫法必須遵循以下原則，這樣做有利於建立索引，提高查詢效率。格式如下select sum（table1.je） from table1 table1, table2 table2, table3 table3 where (table1的等值條件（=）) and (table1的非等值條件) and (table2與table1的關聯條件) and (table2的等值條件) and (table2的非等值條件) and (table3與table2的關聯條件) and (table3的等值條件) and (table3的非等值條件)。
注:關於多表查詢時from 後面表的出現順序對效率的影響還有待研究。
14. 子查詢問題。對於能用連接方式或者視圖方式實現的功能，不要用子查詢。例如：select name from customer where customer_id in ( select customer_id from order where money>1000)。應該用如下語句代替：select name from customer inner join order on customer.customer_id=order.customer_id where order.money>100。
15. 在WHERE 子句中，避免對列的四則運算，特別是where 條件的左邊，嚴禁使用運算與函數對列進行處理。比如有些地方 substring 可以用like代替。
16. 如果在語句中有not in（in）操作，應考慮用not exists（exists）來重寫,最好的辦法是使用外連接實現。
17. 對一個業務過程的處理，應該使事物的開始與結束之間的時間間隔越短越好，原則上做到資料庫的讀操作在前面完成，資料庫寫操作在後面完成，避免交叉。
18. 請小心不要對過多的列使用列函數和order by,group by等，謹慎使用disti軟體開發t。
19. 用union all 代替 union，資料庫執行union操作，首先先分別執行union兩端的查詢，將其放在臨時表中，然後在對其進行排序，過濾重復的記錄。
當已知的業務邏輯決定query A和query B中不會有重復記錄時，應該用union all代替union，以提高查詢效率。
『拾』 如何進行SQL性能優化
這里分享下mysql優化的幾種方法。
1、首先在打開的軟體中，需要分別為每一個表創建 InnoDB FILE的文件。
