如何解释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命令与索引有关的结果

回答

相关问题