如何解釋sp_spaceused命令與索引有關的結果

如果我需要查看超過2000個表的索引，那麼我從哪裏開始從sp_spaceused命令給出信息？如何解釋sp_spaceused命令與索引有關的結果

我在調查表上的索引，但我不太確定在SQL中執行sp_spaceused存儲過程時IndexSize的結果如何。

首先，我可以使用IndexSize和DataSize之間的比率來調用索引是否最佳？例如，如果我的表的DataSize是31 261 768KB並且IndexSize是41 682 120KB，那麼我將indexSize/DataSize * 100除以得到133的比率。我所做的是正確的嗎？如果它是正確的，IndexSize比率是否超過100％不好？

那麼比較好的比例是什麼？

感謝，

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ ~~~~~~ 我需要添加更多信息。

該應用程序是Microsoft Dynamics Ax 4.0。雖然開發人員可以添加新索引，但系統索引不能刪除。

我們目前處於這樣一種情況，那就是沒有添加任何值的自定義索引的分配（空白字段上的索引，金額字段上的索引等）。我正在調查這些作爲代碼清理過程的一部分。

但是，因爲有成千上萬的表需要通過我需要一個起點。我首先關心的是識別不增加價值的自定義索引，爲此我想到了使用sp_spaceused過程。

來源

2011-04-01 Celeste

Performance Analyzer for Microsoft Dynamics可以用來分析價格昂貴，長時間運行的查詢，缺少聚集索引，不正確的，丟失的索引，藏聚簇索引掃描等在AX DB。

一種消除不必要索引量的方法是搜索索引，這些索引是同一個表上另一個索引的左鍵子集。除非子集密鑰是唯一的，否則它的用處包含在超集密鑰中。爲了獲得這種索引列表，你可以運行下面的查詢：

SELECT * 
FROM INDEX_STATS_CURR_VW O 
WHERE INDEX_DESCRIPTION NOT LIKE '%UNIQUE%' 
AND EXISTS 
(
    SELECT * FROM INDEX_STATS_VW I 
    WHERE I.RUN_NAME = O.RUN_NAME 
    AND I.TABLE_NAME = O.TABLE_NAME 
    AND I.INDEX_KEYS <> O.INDEX_KEYS 
    AND I.INDEX_KEYS LIKE O.INDEX_KEYS + ',%' 
    AND O.USER_SEEKS = 0 
) 
ORDER BY TABLE_NAME, INDEX_KEYS

要獲取期間，你可以運行下面的查詢完整的監測期內沒有被使用的所有索引的概述：

SELECT TABLE_NAME, 
    INDEX_NAME, 
    INDEX_DESCRIPTION, 
    INDEX_KEYS, 
    INCLUDED_COLUMNS, 
    SUM(USER_SEEKS) AS USER_SEEKS, 
    SUM(USER_SCANS) AS USER_SCANS, 
    SUM(USER_LOOKUPS) AS USER_LOOKUPS, 
    SUM(USER_UPDATES) AS USER_UPDATES 
FROM INDEX_STATS_VW 
WHERE INDEX_DESCRIPTION NOT LIKE '%UNIQUE%' 
GROUP BY TABLE_NAME, INDEX_NAME, INDEX_DESCRIPTION, INDEX_KEYS, INCLUDED_COLUMNS 
HAVING SUM(USER_SEEKS) = 0 
AND SUM(USER_SCANS) = 0 
AND SUM(USER_LOOKUPS) = 0 
ORDER BY 9 DESC

您還可以識別使用索引的查詢試圖篩選數據：

SELECT TOP 100 * FROM HIDDEN_SCANS_CURR_VW 
ORDER BY TOTAL_ELAPSED_TIME DESC

下將顯示10個最昂貴的查詢，通過平均邏輯下令從A S讀取QL服務器DMV觀點：

SELECT TOP 10 
    SQL_TEXT, 
    QUERY_PLAN, 
    TOTAL_ELAPSED_TIME, 
    AVG_ELAPSED_TIME, 
    MAX_ELAPSED_TIME, 
    AVG_LOGICAL_READS, 
    EXECUTION_COUNT 
FROM QUERY_STATS_CURR_VW 
ORDER BY AVG_LOGICAL_READS DESC

你想也需要看看其他參數，如執行次數（查詢被執行多少次）。

如果你想有運行時間超過1000毫秒，你可以運行下面的查詢AX查詢的概述：

SELECT CONVERT(nvarchar,CREATED_DATETIME,101) AS CREATED_DATE, 
    DATEPART (hh, CREATED_DATETIME) AS HOUR_OF_DAY, 
    COUNT (CREATED_DATETIME) AS EXECUTION_COUNT, 
    SUM (SQL_DURATION) AS TOTAL_DURATION, 
    AVG (SQL_DURATION) AS AVERAGE_DURATION 
FROM AX_SQLTRACE_VW 
WHERE SQL_DURATION > 1000 and CREATED_DATETIME > '04/01/2011' 
GROUP BY CONVERT(nvarchar, CREATED_DATETIME, 101), DATEPART (hh, CREATED_DATETIME) 
ORDER BY CREATED_DATE, HOUR_OF_DAY

希望有所幫助。

來源

2011-04-04 14:12:52 10p

嗨。我認爲INDEX_STATS_CURR_VW是一個視圖？這是不承認，我得到一個「無效的對象.....」錯誤。我正在使用SQL 2005. – Celeste 2011-04-04 15:00:08

您是否安裝了性能分析器（請參閱上面的鏈接）？ – 10p 2011-04-04 20:00:31

還沒有，沒有權利（我們的組織外包了那部分業務）。感謝你的幫助！ – Celeste 2011-04-05 07:10:58

檢查指數大小與數據大小的比率是可怕的指標用於此目的。

唯一應該推動索引創建或修改的是性能。這在很大程度上取決於表格中的活動（很多SELECT s，很多INSERTS/UPDATEs，一些組合）和表格的組成。

不幸的是，這不是一個簡單的答案。索引是數據庫設計中最複雜的一個方面。

我建議你對此做一些閱讀。

Check out Kimberly Tripp's blog here.
她曾MS相當長的一段時間，她的丈夫（保羅·蘭德爾）寫SQL Server中的DBCC程序2005

Gail Shaw also has some good articles in her blog.

來源

2011-04-01 12:32:07 JNK

謝謝，Kimberly Tripp的博客非常有用。 – Celeste 2011-04-04 12:43:40

我不知道你想實現。你會優化一個查詢，而不是索引。但是太多索引會妨礙寫作表現。我建議您查看2005年提供的DMV（動態管理視圖）。

例如select * from sys.dm_index_usage_stats將幫助識別未使用的索引。

有一個與BOL上的索引相關的DMV列表。

http://msdn.microsoft.com/en-us/library/ms187974%28v=SQL.90%29.aspx

來源

2011-04-01 12:44:47

如何解釋sp_spaceused命令與索引有關的結果

回答

相關問題