Sqlserver DMV-sys.dm_db_index_usage_stats

本文介绍SQL Server中sys.dm_db_index_usage_stats视图的使用,该视图提供索引操作计数及最后执行时间,帮助确定应用中较少使用或高维护成本的索引。

 

返回不同类型索引操作的计数以及上次执行每种操作的时间(SQL server服务重启,数据会重置)。

备注

由一个查询执行对指定索引所进行的每个单独的搜索、扫描、查找或更新都被计为对该索引的一次使用,并使此视图中的相应计数器递增。 对于由用户提交的查询所引发的操作以及由内部生成的查询所引发的操作(例如为收集统计信息而进行的扫描),都将报告相应的信息。

User_updates计数器指示的级别引起的插入的索引维护、 更新或删除对基础表或视图的操作。 可以使用此视图确定应用程序极少使用的索引。 还可以使用此视图确定引发维护开销的索引。 您可能要删除引发维护开销但不用于查询或只是偶尔用于查询的索引。

只要启动 SQL Server (MSSQLSERVER) 服务,计数器就初始化为空。 而且,当分离或关闭数据库时(例如,由于 AUTO_CLOSE 设置为 ON),便会删除与该数据库关联的所有行。

使用索引时,将行添加到sys.dm_db_index_usage_stats如果某行的索引尚不存在。 当添加该行时,它的计数器会初始设置为零。

在升级到 SQL Server 2008 R2, SQL Server 2012 (11.x),或 SQL Server 2014 (12.x),sys.dm_db_index_usage_stats 中的项会被删除。开头 SQL Server 2016 (13.x),就像之前保留条目 SQL Server 2008 R2。

列名数据类型Description
database_idsmallint在其中定义表或视图的数据库的 ID。
object_idint为其定义索引的表或视图的 ID。
index_idint索引的 ID。
user_seeksbigint通过用户查询执行的搜索次数。
user_scansbigint通过未使用的用户查询的扫描次数查找谓词。
user_lookupsbigint由用户查询执行的书签查找次数。
user_updatesbigint通过用户查询执行的更新次数。 这包括 Insert、 Delete 和更新表示操作执行不受影响的实际行数。 例如,如果删除在一个语句中的 1000年行,此计数递增 1
last_user_seekdatetime用户上次执行搜索的时间。
last_user_scandatetime用户上次执行扫描的时间。
last_user_lookupdatetime用户上次执行查找的时间。
last_user_updatedatetime用户上次执行更新的时间。
system_seeksbigint通过系统查询执行的搜索次数。
system_scansbigint通过系统查询执行的扫描次数。
system_lookupsbigint通过系统查询执行的查找次数。
system_updatesbigint通过系统查询执行的更新次数。
last_system_seekdatetime系统上次执行搜索的时间。
last_system_scandatetime系统上次执行扫描的时间。
last_system_lookupdatetime系统上次执行查找的时间。
last_system_updatedatetime系统上次执行更新的时间。
pdw_node_idint适用于: Azure SQL 数据仓库, 并行数据仓库
 
对于此分布的节点标识符。

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

<think>嗯,用户有一个SQL Server的Prod_DetectionRecords表,数据量很大,行数超过2.3亿,占用了236.45GB的空间。他们想优化这个表。首先,我得考虑从哪里入手。优化大表通常涉及到索引、分区、归档、结构设计等方面。 首先,应该分析表的当前结构。用户没有提到具体的字段和索引情况,所以可能需要建议他们先检查表结构,看看是否有冗余字段或者可以优化的数据类型。比如,用INT代替BIGINT如果不需要那么大的范围,或者使用更小的日期时间类型。还有,是否有NVARCHAR字段被过度使用,比如本可以用VARCHAR却用了NVARCHAR,导致存储空间翻倍。 接下来是索引方面。索引过多会影响写入性能,并占用更多空间。需要检查现有的索引,看看哪些索引使用频率低,可以删除。同时,检查是否有缺失的索引,特别是对经常查询的字段。使用DMVsys.dm_db_index_usage_stats来查看索引使用情况可能会有帮助。 然后考虑分区。如果表数据有自然的分区键,比如按时间,那么分区表可以提高查询性能,特别是对于历史数据的查询。分区还能帮助更高效地进行数据归档,比如切换分区到另一个表或文件组。 数据归档也是关键。这么大的数据量,可能有很多历史数据不再频繁访问。可以建议用户将旧数据迁移到归档表或不同的数据库中,甚至使用SQL Server的Stretch Database把冷数据迁移到Azure。这样主表的数据量减少,性能会提升。 存储方面,检查表的页和行压缩。启用压缩可以减少磁盘空间占用,提高I/O性能。此外,整理索引碎片也很重要,特别是当索引碎片率超过30%时,重建或重组索引可以改善性能。 查询优化方面,需要分析执行计划,看看是否有全表扫描或者低效的连接操作。建议用户优化查询语句,避免使用SELECT *,只选择需要的列,并确保WHERE条件有效地使用索引。 定期维护任务,比如更新统计信息,确保查询优化器有准确的数据分布信息。自动更新统计信息可能不够,特别是对于大表,可能需要更频繁的更新。 如果硬件允许的话,增加内存、使用SSD,或者优化磁盘阵列配置也能提升性能。此外,考虑读写分离,将读操作转移到只读副本,减轻主库压力。 最后,监控和持续优化。使用SQL Server的监控工具跟踪性能指标,定期审查优化措施的效果,并根据实际情况调整策略。 可能还需要提醒用户,具体优化步骤需要根据实际使用情况来调整,比如业务需求、查询模式、硬件配置等。最好在操作前备份数据,特别是在进行索引重建或结构调整时,避免意外发生。</think>针对SQL Server中数据量巨大的`Prod_DetectionRecords`表(2.3亿+行,236GB+),优化需分步骤进行。以下是系统性优化方案: --- ### **一、基础分析** 1. **查看表结构** ```sql sp_help 'Prod_DetectionRecords'; ``` - 确认字段类型是否合理(例如用`smalldatetime`替代`datetime`可节省4字节/行) - 检查是否有冗余字段或可合并的`NVARCHAR(MAX)`字段 2. **空间分布分析** ```sql EXEC sp_spaceused 'Prod_DetectionRecords'; ``` - 观察`data`、`index_size`、`unused`的分布,判断是数据还是索引占主导 --- ### **二、索引优化** 1. **索引精简** - 删除未使用的索引: ```sql SELECT * FROM sys.dm_db_index_usage_stats WHERE object_id = OBJECT_ID('Prod_DetectionRecords'); ``` - 合并覆盖索引(例如将单列索引合并为复合索引) 2. **缺失索引推荐** ```sql SELECT * FROM sys.dm_db_missing_index_details WHERE object_id = OBJECT_ID('Prod_DetectionRecords'); ``` 3. **索引压缩** ```sql ALTER INDEX [IndexName] ON Prod_DetectionRecords REBUILD WITH (DATA_COMPRESSION = PAGE); ``` --- ### **三、数据归档与分区** 1. **按时间分区** ```sql CREATE PARTITION FUNCTION PF_DetectionDate (DATETIME) AS RANGE RIGHT FOR VALUES ('2020-01-01', '2021-01-01', '2022-01-01'); CREATE PARTITION SCHEME PS_DetectionDate AS PARTITION PF_DetectionDate TO (fg_old, fg_2020, fg_2021, fg_current); ``` - 将历史数据迁移到低成本存储文件组(如SSD与HDD分离) 2. **数据归档** ```sql -- 将早于2020年的数据迁移到归档表 SELECT * INTO Prod_DetectionRecords_Archive FROM Prod_DetectionRecords WHERE DetectionDate < '2020-01-01'; -- 删除原表过期数据 DELETE FROM Prod_DetectionRecords WHERE DetectionDate < '2020-01-01'; ``` --- ### **四、存储优化** 1. **启用数据压缩** ```sql ALTER TABLE Prod_DetectionRecords REBUILD WITH (DATA_COMPRESSION = PAGE); ``` - 预估压缩率:`sp_estimate_data_compression_savings` 2. **碎片整理** ```sql ALTER INDEX ALL ON Prod_DetectionRecords REORGANIZE; -- 碎片率<30% ALTER INDEX ALL ON Prod_DetectionRecords REBUILD; -- 碎片率≥30% ``` --- ### **五、查询优化** 1. **避免全表扫描** - 强制使用索引:`WITH (INDEX(IndexName))` - 禁止`SELECT *`,明确列出字段 2. **批处理操作** ```sql WHILE EXISTS(SELECT 1 FROM Prod_DetectionRecords WHERE Condition) BEGIN DELETE TOP (5000) FROM Prod_DetectionRecords WHERE Condition; CHECKPOINT; END ``` --- ### **六、硬件与配置优化** 1. **内存与磁盘** - 确保`max server memory`为物理内存的80-90% - 将数据文件(`MDF`)和日志文件(`LDF`)分离到不同物理磁盘 2. **开启即时文件初始化** - 减少数据文件增长时的延迟(需`SE_MANAGE_VOLUME_NAME`权限) --- ### **七、监控维护** 1. **统计信息更新** ```sql UPDATE STATISTICS Prod_DetectionRecords WITH FULLSCAN; ``` 2. **自动化作业** - 每周重建高碎片索引 - 每日更新统计信息 --- ### **效果预估** | 优化项 | 预计空间节省 | 性能提升方向 | |-----------------------|--------------|--------------------| | 数据压缩 | 30%~60% | I/O效率提升 | | 索引精简 | 5%~20% | 写入速度提升 | | 分区+归档 | 40%~70% | 查询范围缩小 | --- ### **注意事项** 1. **测试环境验证**:所有操作需先在非生产环境验证 2. **事务日志管理**:大批量操作前确保日志文件有足够空间 3. **备份优先**:优化前执行全量备份 通过综合应用上述策略,可显著降低存储压力并提升查询效率。需根据实际业务访问模式调整优先级。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值