Question

因为我必须维护几个数据库和超过1000个大量DML操作的表，所以我想过使用触发器自动将索引碎片级别维持在某个值以下。

我只觉得我现在没有时间去做，所以不会提供我的代码。当然，我在脑海中有一些通用的架构如何做到这一点。我能够构建一个触发器，我知道如何找到索引碎片值。但是，如果没有大量的测试和大量的文档阅读，我不知道如何做到这一点，尽可能减少错误和最佳。它甚至可能是不可能的，因为我对触发器及其限制知之甚少，并且在触发器中可能不允许执行此任务所需的一些操作。

例如，有些事情困扰我：

使用在线或离线索引
此类触发器可能会导致查询崩溃
因为超时，有可能不执行触发一些单行更新，但是当完整查询完成时，由于在苍蝇中进行索引重建而无法粉碎

那么如何以最佳方式实现这样的任务呢？有关此类触发器如何影响查询性能的任何信息也将受到赞赏。

修改因为要求我会提供一些代码。它可能是完整的解决方案，但是当触发触发时它会生成错误消息：'无法在/使用表'schema.table'上执行ALTER INDEX，因为该表是目标表或当前正在执行的触发器的级联操作的一部分'

CREATE TRIGGER defragmentator ON [schema].[table]
AFTER INSERT, UPDATE
AS
    DECLARE @fragRate float;

    SELECT @fragRate = a.avg_fragmentation_in_percent
    FROM sys.dm_db_index_physical_stats (DB_ID(N'MyDB'), OBJECT_ID(N'[schema].[table]'), NULL, NULL, NULL) AS a
    JOIN sys.indexes AS b ON a.object_id = b.object_id AND a.index_id = b.index_id
    WHERE b.name = 'IDX_name';

    IF @fragRate > 50
    ALTER INDEX IDX_name ON [schema].[table]
    REBUILD
GO

如何改进？

Answer 1

这是个坏主意。应在您的业务定义的维护窗口期间执行索引操作。具有预定作业的SQL代理是更优选的解决方案。

超过给定的碎片级别后触发重建索引

1 个答案: