『壹』 PL/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條件有等號的情況下才可以使用。哈希連接在表的數據量較大，表中沒有合適的索引可用時比嵌套循環的效率要高。
『貳』 請教oracle中 sql語句效率怎麼測試
看執行計劃。
select p.* from v$sql_plan p ,v$session s where p.SQL_ID=s.SQL_ID and s.SID='XXXX'；
或者是通過pl/sql developer 的 工具來看。
如果你不懂什麼是執行計劃，那就比較困難了
『叄』 如何測試sql語句性能，提高執行效率
有時候我們經常為我們的sql語句執行效率低下發愁，反復優化後，可還是得不到提高
那麼你就用這條語句找出你sql到底是在哪裡慢了
示例：
SET STATISTICS io ON
SET STATISTICS time
ON
go
---你要測試的sql語句
select top 100 * from
TBL_Cot_RecStaticList
go
SET STATISTICS profile
OFF
SET STATISTICS io OFF
SET STATISTICS time OFF
顯示信息：
SQL Server 分析和編譯時間:
CPU 時間 = 0 毫秒，佔用時間 = 59 毫秒。
(100 行受影響) 表 'TBL_Cot_RecStaticList'。掃描計數 1，邏輯讀取 14 次，物理讀取 2
次，預讀 992 次，lob 邏輯讀取 0 次，lob 物理讀取 0 次，lob 預讀 0 次。
SQL Server 執行時間: CPU 時間 = 0 毫秒，佔用時間 = 306 毫秒。
SQL Server 分析和編譯時間: CPU 時間 = 0 毫秒，佔用時間 = 1 毫秒。
SQL Server 執行時間: CPU 時間 = 0 毫秒，佔用時間 = 1 毫秒。
SQL Server 執行時間: CPU 時間 = 0 毫秒，佔用時間 = 1 毫秒。
『肆』 百萬數據下幾種SQL性能測試
由於在參與的實際項目中發現當mysql表的數據量達到百萬級時，普通SQL查詢效率呈直線下降，而且如果where中的查詢條件較多時，其查詢速度簡直無法容忍。曾經測試對一個包含400多萬條記錄（有索引）的表執行一條條件查詢，其查詢時間竟然高達40幾秒，相信這么高的查詢延時，任何用戶都會抓狂。因此如何提高sql語句查詢效率，顯得十分重要。以下是網上流傳比較廣泛的30種SQL查詢語句優化方法：
1、應盡量避免在 where 子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。
2、對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
3、應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
select id from t where num is null
可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
select id from t where num=0
『伍』 如何做SQL Server性能測試
為了模擬資料庫的負載，你想要有多個應用程序用戶和混合數據讀寫的語句。你不想總是對單一行更新相同的值，或者只是重復插入假的值。
自己動手使用Powershell、C#等語言寫負載測試腳本也不是不可能，只是太消耗時間，你需要創建或者恢復資料庫，並做對應的測試。
免費而簡單的壓測SQL Server：使用HammerDB模擬OLTP資料庫負載
HammerDB是一個免費、開源的工具，允許你針對SQL Server、Oracle、MySQL和PostgreSQL等運行TPC-C和TPC-H基準測試。你可以使用HammerDB來針對一個資料庫生成腳本並導入測試。HammerDB也允許你配置一個測試運行的長度，定義暖機階段，對於每個運行的虛擬用戶的數量。
首先，HammerDB有一個自動化隊列，讓你將多個運行在不同級別的虛擬用戶整合到一個隊列--你可以以此獲得在什麼級別下虛擬用戶性能平穩的結果曲線。你也可以用它來模擬用於示範或研究目的的不同負載。
用於SQL Server上的HammerDB的優缺點
HammerDB是一個免費工具，它也極易訪問和快速的啟動基準測試和模擬負載的方法。它的自動程序特性也是的運行工作負載相當自動。
主要缺點是它有一個學習曲線。用戶界面不是很直觀，需要花費時間去習慣。再你使用這個工具一段時間之後，將會更加容易。
『陸』 如何測試mysql sql執行效率
效率你自己執行下就看得出了......我估計是一樣的，因為2條語句都是採用嵌套循環查詢，如果我選的話，會選where u.USERID=f.userid and u.userid=a.userid這種形式，因為看著順眼點~~~
非要優化的話，可以在f.star、downmoney、u.userid列上加索引，看看錶的大小和列的離散度再考慮是否需要加吧。
『柒』 oracle 一個簡單的sql語句執行效率的比較
比較一下的話，語句一查詢次數是兩次，而語句二隻有一次，我們盡量減少查詢次數。
語句一其實就是二的另一種實現，其效果是和語句一相同，但多了很多中間不必要的步驟，所以肯定優先選擇二。
至於SQL效率問題多看看別人總結的經驗會很快了解，多看執行計劃。
查看執行計劃在SQL PLUS下可以用：explain sql語句；
PLSQL DEVELOPTER下可以寫好語句直接按F5;
我們通常知道使用索引要比全表好，使用索引的時候，ORACLE先通過索引快速找到記錄的物理地址，然後再通過物理地址找到記錄。全表則是直接掃描所有記錄，找到想要的，看起來慢多了，但它少了通過索引查找物理地址這一步，所以在有些情況下可能要比索引快，比如表裡的記錄很少。
綁定變數，你可以參考：
http://..com/question/298893776?&oldq=1
還有子查詢，group by，in，not in，很多人都說盡量不用，其實這些都不能一概而論，要看具體的實際情況，參考執行計劃，根據需要去選擇，千萬別有偏見
『捌』 如何測試sql語句性能，提高執行效率，sql2008
一段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條件有等號的情況下才可以使用。哈希連接在表的數據量較大，表中沒有合適的索引可用時比嵌套循環的效率要高。