SQL Server 的 DDL 触发器不支持 DROP INDEX 事件，因其未被官方列为受支持的 DDL 事件类型，索引删除被视为底层元数据操作而非独立可捕获事件。
为什么不能直接用触发器监控 DROP INDEX
SQL Server 的 DDL 触发器不支持 DROP INDEX 事件。你执行 DROP INDEX table_name.index_name 时，触发器根本不会被激活——这不是遗漏配置，而是 SQL Server 明确不提供该事件类型。官方文档明确列出受支持的 DDL 事件（如 ALTER_INDEX、DROP_TABLE），但 DROP_INDEX 不在其中。
这是因为索引删除本质上是表结构变更的副作用，SQL Server 将其归入更底层的元数据操作，未暴露为独立可捕获的 DDL 事件。
替代方案：用 DDL 触发器捕获 ALTER_INDEX 和 DROP_TABLE
虽然无法拦截 DROP INDEX，但你可以捕获实际导致索引消失的两类操作：
-
ALTER INDEX ... DISABLE或REBUILD可能间接使索引失效或重建失败，触发ALTER_INDEX事件 -
DROP TABLE会连带删除所有关联索引，这个事件完全可捕获 - 某些工具或脚本可能先
ALTER TABLE ... DROP CONSTRAINT（主键/唯一约束），再删索引，这类操作会触发ALTER_TABLE
示例：监控表级结构变更
CREATE TRIGGER tr_audit_index_impact
ON DATABASE
FOR ALTER_TABLE, DROP_TABLE, ALTER_INDEX
AS
BEGIN
DECLARE @event_data XML = EVENTDATA();
DECLARE @obj_name SYSNAME = @event_data.value('(/EVENT_INSTANCE/ObjectName)[1]', 'SYSNAME');
DECLARE @obj_type VARCHAR(50) = @event_data.value('(/EVENT_INSTANCE/ObjectType)[1]', 'VARCHAR(50)');
DECLARE @tsql NVARCHAR(MAX) = @event_data.value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]', 'NVARCHAR(MAX)');
IF @obj_type = 'INDEX' OR (@obj_type = 'TABLE' AND @tsql LIKE '%DROP%INDEX%')
BEGIN
INSERT INTO dbo.AuditLog (EventType, ObjectName, TSQL, EventTime)
VALUES ('DDL_INDEX_IMPACT', ISNULL(@obj_name, '(unknown)'), @tsql, GETDATE());
END
END;
真正可靠的索引变更监控：用 sys.dm_db_index_usage_stats + 定时轮询
DDL 触发器有盲区，而索引是否还存在是确定性事实。最稳的方式是绕过“拦截”，改用“发现”：
-
sys.dm_db_index_usage_stats中的last_user_lookup/last_user_scan会随索引使用更新，但索引删除后该行直接消失 - 定期查询
sys.indexes并比对快照：比如每 5 分钟跑一次SELECT object_id, name, type_desc FROM sys.indexes WHERE type_desc 'HEAP'，和上次结果做差集 - 把差集写入审计表，并标记
missing_since = GETDATE()，就能确认是何时消失的
注意：该 DMV 在服务重启后清空，所以需搭配持久化快照表使用，不能只依赖 DMV 实时值。
容易忽略的关键点：权限与性能开销
DDL 数据库级触发器需要 ALTER ANY DATABASE DDL TRIGGER 权限，且一旦启用，每个匹配的 DDL 操作都会同步执行触发器逻辑——如果审计表写入慢或网络延迟高，会拖慢 DROP TABLE 等关键操作。
而轮询方案虽不实时，但可控：你可以把快照比对放在低峰期作业中运行，避免阻塞业务；同时，sys.indexes 是系统视图，查询极轻量，即使上千张表也毫秒级返回。
真正的难点不在“怎么写”，而在“怎么确认它确实消失了”——必须接受 DDL 触发器不是万能的，索引生命周期管理需要混合手段。
