『壹』 如何利用QUEST sql OPTIMIZER來優化復雜的SQL
使用QUEST SQL OPTIMIZER工具，你把SQL放到它裡面運行，他會自動找出N種方案，你看哪個時間最少，就用哪個
『貳』 資料庫系統優化的LECCO SQL Expert自動優化實例
假設我們從源代碼中抽取出這條SQL語句(也可以通過內帶的掃描器或監視器獲得SQL語句)：
SELECT COUNT(*)
FROM EMPLOYEE
swheresEXISTS (SELECT 'X'
FROM DEPARTMENT
swheresEMP_DEPT=DPT_ID
AND DPT_NAME LIKE 'AC%')
AND EMP_ID IN (SELECT SAL_EMP_ID
FROM EMP_SAL_HIST B
swheresSAL_SALARY > 70000)
按下「優化」按鈕後，經過10幾秒，SQL Expert就完成了優化的過程，並在這10幾秒的時間里重寫產生了2267 條等價的SQL語句，其中136條SQL語句有不同的執行計劃。
接下來，我們可以對自動重寫產生的136條SQL語句進行批運行測試，以選出性能最佳的等效SQL語句。按下「批運行」 按鈕，在「終止條件」 頁選擇「最佳運行時間SQL語句」，按「確定」。
經過幾分鍾的測試運行後，我們可以發現SQL124的運行時間和反應時間最短。運行速度約有22.75倍的提升(源SQL語句運行時間為2.73秒，SQL124運行時間為0.12秒)。現在我們就可以把SQL124放入源代碼中，結束一條SQL語句的優化工作了。
『叄』 怎樣進行sql資料庫的優化
1、資料庫空間是個概述，在sqlserver里，使用語句 exec sp_spaceused 'TableName' 這個語句來查。
『肆』 資料庫牛人是如何進行SQL優化的
SQL 查詢優化減少了查詢所需的資源並提高了整體系統性能，在本文中，我們將討論 SQL 查詢優化、它是如何完成的、最佳實踐及其重要性。
SQL 查詢優化是編寫高效的 SQL 查詢，並在執行時間和資料庫表示方面 提高查詢性能 的迭代過程，查詢優化是幾個關系資料庫管理系統 (RDBMS) 的一項重要功能。
查詢是對來自資料庫的數據或信息的問題或請求，需要編寫一組資料庫可以理解的預定義代碼，結構化查詢語言 (SQL) 和其他查詢語言旨在檢索或管理關系資料庫中的數據。
資料庫中的查詢可以用許多不同的結構編寫，並且可以通過不同的演算法執行，寫得不好的查詢會消耗更多的系統資源，執行時間長，並可能導致服務損失，一個完美的查詢可以減少執行時間並帶來最佳的 SQL 性能。
SQL查詢優化的主要目的是：
確保查詢處於最佳路徑和形式非常重要，SQL 查詢過程需要最好的執行計劃和計算資源，因為它們是 CPU 密集型操作，SQL 查詢優化通過三個基本步驟完成：
解析確保查詢在語法和語義上都是正確的，如果查詢語法正確，則將其轉換為表達式並傳遞到下一步。
優化在查詢性能中扮演著重要的角色，並且可能很困難，任何考慮優化的查詢執行計劃都必須返回與之前相同的結果，但優化後的性能應該會有所提高。
SQL 查詢優化包括以下基本任務：
最後，查詢執行涉及將查詢優化步驟生成的計劃轉化為操作，如果沒有發生錯誤，此步驟將返回結果給用戶。
一旦用戶確定某個查詢需要改進以優化 SQL 性能，他們就可以選擇任何優化方法——優化 SQL 查詢性能的方法有很多種，下面介紹了一些最佳實踐。
提高查詢性能的一種簡單方法是將 SELECT * 替換為實際的列名，當開發人員在表中使用 SELECT * 語句時，它會讀取每一列的可用數據。
使用 SELECT 欄位名 FROM 而不是 SELECT * FROM 時，可以縮小查詢期間從表中提取的數據的范圍，這有助於提高查詢速度。
循環中的 SQL 查詢運行不止一次，這會顯著降低運行速度，這些查詢會不必要地消耗內存、CPU 能力和帶寬，這會影響性能，尤其是當 SQL 伺服器不在本地計算機上時，刪除循環內的查詢可提高整體查詢性能。
使用SQL 伺服器索引可以減少運行時間並更快地檢索數據，可以使用聚集和非聚集 SQL 索引來優化 SQL 查詢，非聚集索引單獨存儲，需要更多的磁碟空間，因此，了解何時使用索引很重要。
該OLAP功能「擴展了SQL解析函數的語法。」 SQL 中的 OLAP 功能更快且易於使用，熟悉這些語法的 SQL 開發人員和 DBA 可以很容易地適應和使用它們。
OLAP 函數可以創建所有標准計算度量，例如排名、移動聚合、份額、期初至今、前期和未來期、平行期等。
查詢優化器使用統計信息來確定如何最好地連接表、何時應該使用索引以及如何訪問這些索引等，無論是手動還是自動，SQL 伺服器統計信息都應該保持最新。
過時的 SQL Server 統計信息會影響表、索引或列統計信息，並導致查詢計劃性能不佳。
SQL 查詢優化可以輕松提高系統性能，從而節省成本，優化 SQL 查詢可以提高運營效率並加快性能，從而提高系統上線進度。
SQL 查詢優化很重要，原因有很多，包括：
組織可以通過更快的響應時間獲得可靠的數據訪問和高水平的性能，優化 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、一次更新多條記錄比分多次更新每次一條快,就是說批處理好
『陸』 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優化之出現。
『柒』 如何用一款小工具大大加速MySQL SQL語句優化
1.將經常要用到的欄位（比如經常要用這些欄位來排序，或者用來做搜索），則最好將這些欄位設為索引。 2.欄位的種類盡可能用int 或者tinyint類型。另外欄位盡可能用NOT NULL。 3.當然無可避免某些欄位會用到text ,varchar等字元類型，最好將text欄位的單獨出另外一個表出來（用主鍵關聯好） 4.欄位的類型，以及長度，是一個很考究開發者優化功力的一個方面。如果表數據有一定的量了，不妨用PROCEDURE ANALYSE()命令來取得欄位的優化建議！（在phpmyadmin里可以在查看錶時，點擊 「Propose table structure」 來查看這些建議） 如此可以讓你的表欄位結構 趨向完善。 5.select * 盡量少用，你想要什麼欄位 就select 什麼欄位出來 不要老是用* 號！同理，只要一行數據時盡量使用 LIMIT 1 6.絕對不要輕易用order by rand() ，很可能會導致mysql的災難！！ 7.每個表都應該設置一個ID主鍵，最好的是一個INT型，並且設置上自動增加的AUTO_INCREMENT標志，這點其實應該作為設計表結構的第一件必然要做的事！！ 8.拆分大的 DELETE 或 INSERT 語句。因為這兩個操作是會鎖表的，表一鎖住了，別的操作都進不來了，就我來說 有時候我寧願用for循環來一個個執行這些操作。 9.不要用永久鏈接 mysql_pconnect()；除非你真的非常肯定你的程序不會發生意外，不然很可能也會導致你的mysql死掉。 10.永遠別要用復雜的mysql語句來顯示你的聰明。就我來說，看到一次關聯了三，四個表的語句，只會讓人覺得很不靠譜。
『捌』 如何用一款小工具大大加速MySQL SQL語句優化
其實MySQL自帶查詢優化器啊。
explain SELECT id,name from tablename where id = 10;root@localhost [test]>explain select id,k from sbtest1 where id =1000\G*************************** 1. row *************************** id: 1 select_type: SIMPLE table: sbtest1 partitions: NULL type: constpossible_keys: PRIMARY key: PRIMARY key_len: 4 ref: const rows: 1 filtered: 100.00 Extra: NULL1 row in set, 1 warning (0.02 sec)這個就告訴你，這一條語句是如何執行的。possible_keys，只可能會走的索引key:是實際走的索引，這里走的是主鍵索引哈。sql優化還有很多知識，一般都用這個來查看執行計劃。具體細節你需要再去翻看資料。##基礎內容可以看看這里。使用MariaDB資料庫管理系統。#MariaDB和MySQL使用上大致一樣的。
『玖』 列舉sql優化有哪些方式方法 博客園
sql優化的方式有：
1、選擇最有效率的表名順序(只在基於規則的優化器中有效)：
ORACLE 的解析器按照從右到左的順序處理FROM子句中的表名，FROM子句中寫在最後的表(基礎表 driving table)將被最先處理，在FROM子句中包含多個表的情況下,你必須選擇記錄條數最少的表作為基礎表。如果有3個以上的表連接查詢, 那就需要選擇交叉表(intersection table)作為基礎表, 交叉表是指那個被其他表所引用的表。
2、WHERE子句中的連接順序：
ORACLE採用自下而上的順序解析WHERE子句,根據這個原理,表之間的連接必須寫在其他WHERE條件之前, 那些可以過濾掉最大數量記錄的條件必須寫在WHERE子句的末尾。
3、SELECT子句中避免使用 『 * 『：
ORACLE在解析的過程中, 會將'*' 依次轉換成所有的列名, 這個工作是通過查詢數據字典完成的, 這意味著將耗費更多的時間 。
4、 減少訪問資料庫的次數：
ORACLE在內部執行了許多工作: 解析SQL語句, 估算索引的利用率, 綁定變數 , 讀數據塊等。
5、 在SQL*Plus , SQL*Forms和Pro*C中重新設置ARRAYSIZE參數, 可以增加每次資料庫訪問的檢索數據量 ,建議值為200 。
6、 使用DECODE函數來減少處理時間：
使用DECODE函數可以避免重復掃描相同記錄或重復連接相同的表。
7、整合簡單,無關聯的資料庫訪問：
如果你有幾個簡單的資料庫查詢語句,你可以把它們整合到一個查詢中(即使它們之間沒有關系)。
『拾』 【DB2】SQL優化
於我來說，我喜歡技術，不偏執於某一類開發語言，願意花時間精力去解決問題。
1.去除在謂詞列上編寫的任何標量函數
優化前：(耗時3.1s)
優化後：(耗時0.922s)
總結：
DB2可以選擇使用START_DATE上的列索引，但是在列上使用了函數後，DB2就無法使用列索引了，從而導致查詢效率變低。
2.去除在謂詞列上編寫的任何數學運算
優化前：(耗時10.265)
優化後：(耗時3.39s)
總結：
DB2查詢時候，會優先選擇列CONTRACT_AMT上的索引，如果直接對列CONTRACT_AMT應用數學運算，DB2就無法使用索引了。一定要做到：列本身(不加數學運算)放在操作符的一邊，而所有的計算都放在另外一邊。
3.SQL語句中指定查詢列
優化前：(耗時13.15s)
優化後：(耗時2.922s)
總結：
如果Select包含不需要的列，優化工具會選擇Indexonly=』N』,這會強制DB2必須進入數據頁來得到所請求的特定列，這就要求更多的I/O操作，梁歪，這些多餘的列可能是某些排序的部分，這樣一來就需要和傳遞一個更大的排序文件，相應的會使排序成本更高。
4.盡可能不使用distinct
優化前：(耗時0.687s)
優化後：(耗時0.437s)
總結：
在測試distinct與group by性能的過程中，在列CST_ID上添加索引後，發現group by 確實比distinct快一些，但是在數據分布比較離散的情況下使用group by ，比較集中的情況下使用distinct.表數據量較少的情況隨便使用哪個都一樣， 不管選擇誰，都要建立索引
5.Exists、in、not in 、not exists的使用場景選擇
5.1 in跟exists的區別：
例如：表A(小表)，表B(大表)
優化前：(耗時1.93s)
優化後：(耗時1.125s)
相反的，
優化前：(耗時1.9s)
優化後：(耗時1.0s)
總結：
in是把外表和內表作hash連接，而exists是對外表作loop循環，每次loop循環再對內表進行查詢，一直以來認為exists比in效率高的說法是不準確的。 如果查詢的兩個表大小相當，那麼用in和exists差別不大；如果兩個表中一個較小一個較大，則子查詢表大的用exists，子查詢表小的用in；
簡稱：子大Exists,子小in
5.2 not in 與 not exists區別：
如果查詢語句使用了not in，那麼對內外表都進行全表掃描，沒有用到索引；而not exists的子查詢依然能用到表上的索引。所以無論哪個表大，用not exists都比not in 要快。
6.盡可能使用union all來代替union
優化前：(耗時15.344s)
優化後：(耗時2.719s)
總結：
在union中，DB2最後會自動執行一個排序來消除重復值，這樣是很耗費資源的，所以在不需要去重復的情況下，盡可能使用UNION ALL 代替union
N.模板
優化前：(耗時3.1s)
優化後：(耗時0.922s)
總結：