查看sql語句性能

1. plsql中語句性能如何查看

V_$SQLAREA視圖提供了執行的細節。(執行、讀取磁碟和讀取緩沖區的次數)
--性能最差的SQL
SELECT * FROM ( SELECT PARSING_USER_ID EXECUTIONS,SORTS,COMMAND_TYPE,DISK_READS,sql_text
FROM v$sqlarea
ORDER BY disk_reads DESC)
WHERE ROWNUM<200
--效率最低的語句
Select EXECUTIONS,DISK_READS,BUFFER_GETS,
ROUND((BUFFER_GETS-DISK_READS)/BUFFER_GETS,2) Hit_radio,
ROUND(DISK_READS/EXECUTIONS,2) Reads_per_run,
SQL_TEXT
From V$SQLAREA
WHERE EXECUTIONS>0 And BUFFER_GETS>0 And (BUFFER_GETS-DISK_READS)/BUFFER_GETS<0.8
ORDER By 4 DESC;

2. 從哪些方面，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條件有等號的情況下才可以使用。哈希連接在表的數據量較大，表中沒有合適的索引可用時比嵌套循環的效率要高。

3. 關於sql語句的性能問題

在多數情況下是第二效率最高，直接使用索引進行篩選。第一種在進行union的時候會進行一些額外的操作，第三種在某些早期資料庫、桌面資料庫、簡單資料庫下可能會不走索引。

4. 檢查SQL語句性能

exlpain sql語句

5. 【查詢優化】怎樣用SQL語句查看查詢的性能指標

（有關TSQL語句查詢所產生的磁碟活動量） --顯示有關由Transact-SQL 語句生成的磁碟活動量的信息 SET STATISTICS IOON--關閉有關由Transact-SQL 語句生成的磁碟活動量的信息 SET STATISTICS IOOFF 顯示的信息如下： （SQL語句為：select * fromnote500）其中： 掃描計數：在查詢中涉及到的表被訪問的次數； 邏輯讀取：從數據緩沖中讀取的數據頁數； 物理讀取：從物理磁碟中往緩沖讀取的數據頁數； 預讀：根據執行計劃從物理磁碟中往緩沖讀取的數據頁數； 其中對於首次查詢一般情況下會有一下關系：邏輯讀取=物理讀取+預讀(其中的具體聯系，由於已經在之前的博客文章中提到，就不再詳細說明（文章名為 【查詢優化】MSSQL查詢執行流程）) 同理，後面的lob邏輯讀取、物理讀取、預讀概念理解差不多，只是是對相應表進行更新或插入操作時體現。 對於掃描計數，以上圖片的查詢沒有連接查詢，因此意義不大。不過，如果連接查詢來說，特別是循環查詢那種，比如說自連接，如果循環次數越多，則掃描次數也就越多，則會使得查詢的效率越低。這是掃描計數是一個比較重要的性能體現參數。 對於邏輯讀取，由於SQLSERVER中對數據進行任何操作都要把數據讀入到緩沖當中，如果邏輯讀取的頁數越多，則查詢的性能越低。為此，邏輯讀取一般都是查詢性能體現的一個重要參數。 二、SET STATISTICSTIME（SQL Server解析和編譯時間） 上面顯示的信息表明，執行這次查詢使用了多少CPU運行時間和運行查詢使用了多少時間。CPU運行時間是對運行查詢所需要的CPU資源的一種相對穩定的測量方法，與CPU的忙閑程度沒有關系。但是，每次運行查詢時這一數字也會有所不同，只是變化的范圍沒有總時間變化大。總時間是對查詢執行所需要的時間（不計算阻塞或讀數據的時間），由於伺服器上的負載是在不斷變化的，因此這一數據的變化范圍有時會相當地大。 總的來說，量化地來看一個查詢語句的性能可以在幾個參數進行比較： 1、CPU時間。比較查詢所要佔用的CPU資源時間； 2、I/O。可以比較查詢的循環掃描次數和邏輯讀取的數據量；

6. sql語句，性能問題

寫一個過程，
從blackuser_temp 表循環取出msisdn，再循環刪除blackuser表中相應msisdn的數據。
這樣可以保證執行計劃穩定。保證效率。一個前提是你的blackuser表需要有msisdn的索引。否則怎麼弄都是一個慢。
過程大概這樣寫，你可以根據需要加其他邏輯：
create or replace procere del_black_user_p
as
cursor msisdn_cur is select msisdn from blackuser_temp;
begin
for rec in msisdn_cur loop
delete /*+ index(blackuser) */ blackuser where msisdn = rec.msisdn;
end loop;
commit; --根據需要考慮加不加commit；或者考慮用計數器計數再批量提交。
end;

7. 如何測試sql語句性能，提高執行效率，sql2008

你是用什麼工具？如果你用的是plsql/developer。你執行計劃就行了。
選中你語句，按F5,可以看出語句塊執行的效率，從而分析出哪一塊效率低下需要優化

8. 如何測試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 毫秒。

9. 幾個檢查資料庫性能的SQL語句

SIMPLE：簡單SELECT(不使用UNION或子查詢等)
PRIMARY：最外面的SELECT
UNION：UNION中的第二個或後面的SELECT語句
DEPENDENTUNION：UNION中的第二個或後面的SELECT語句，取決於外面的查詢
UNIONRESULT：UNION的結果。
SUBQUERY：子查詢中的第一個SELECT
DEPENDENTSUBQUERY：子查詢中的第一個SELECT，取決於外面的查詢
DERIVED：導出表的SELECT(FROM子句的子查詢)

10. 分析此sql語句的性能

1.這條sql的性能要看錶a的數據量大小，以及xm為空的記錄數多少，沒什麼可優化的了
2.不清楚你在問什麼，你現在不就是在批量更新么
3.相同的where條件的話當然是select快一些。
4.沒多少捷徑，建議先看些基礎的concept，然後再談優化。基本概念最重要