SQL Server 不能用 DML 触发器拦截 DROP INDEX，因其是 DDL 操作；必须使用 ON DATABASE 的 DDL 触发器捕获 DROP_INDEX 事件，并通过 EVENTDATA() 解析对象名，配合 RAISERROR(16) 和上下文校验（如 CONTEXT_INFO）实现精准拦截。
SQL Server 不能用 DML 触发器拦截 DROP INDEX
直接回答：DROP INDEX 是 DDL 操作，INSTEAD OF DELETE 或 AFTER DELETE 这类 DML 触发器完全不响应它。试图在表上建 DELETE 触发器来防删索引，注定失效——因为根本不会触发。
常见错误现象：开发人员在 sysindexes 或 sys.indexes 上建了触发器，结果 DROP INDEX IX_Orders_CreatedAt ON orders 照常执行，毫无拦截效果。
真正起作用的是 DDL 触发器，且必须显式绑定到数据库级（ON DATABASE），不是表级。
必须用 ON DATABASE 的 DDL 触发器捕获 DROP_INDEX 事件
SQL Server 的 DDL 触发器能监听 DROP_INDEX 事件，但有硬性前提：
- 触发器必须创建在目标数据库上下文中（不是
master） - 创建后默认是禁用状态，必须手动执行
ENABLE TRIGGER tr_block_drop_index ON DATABASE - 必须用
EVENTDATA()解析 XML，从中提取真实操作对象，OBJECT_NAME()在 DDL 触发器中返回NULL
关键字段提取示例：
DECLARE @ObjectName sysname = CAST(EVENTDATA() AS XML).value('(/EVENT_INSTANCE/ObjectName)[1]', 'sysname');
DECLARE @SchemaName sysname = CAST(EVENTDATA() AS XML).value('(/EVENT_INSTANCE/SchemaName)[1]', 'sysname');
注意：/EVENT_INSTANCE/ObjectName 节点名大小写敏感，写成 objectname 就解析失败；未加 TRY...CATCH 包裹解析逻辑时，XML 结构微调（如新版 SQL Server 改字段）会导致整个触发器报错中断合法运维。
只拦危险操作，放行维护脚本的白名单机制
硬性禁止所有 DROP INDEX 会卡住备份还原、索引重建等必要流程。得靠上下文区分“谁在删”和“为什么删”：
- 优先检查
PROGRAM_NAME()：人工操作通常带SQLServerManagementStudio或sqlcmd，归档或维护脚本应统一设为INDEX_MAINTENANCE - 避免依赖
ORIGINAL_LOGIN()单一账号：ETL 和 DBA 可能共用db_owner账号，仅校验登录名无法区分意图 - 更灵活的方式是脚本开头执行
SET CONTEXT_INFO 0x494E4445585F4D41494E（即 "INDEX_MAIN" 的 ASCII 十六进制），触发器里用CONTEXT_INFO()检查
错误做法：用 LIKE '%temp%' 模糊匹配索引名放行，攻击者可建 IX_orders_temp_drop_me 绕过。
RAISERROR 必须 ≥16 级且配合事务控制
DDL 触发器中仅 RAISERROR('xxx', 10, 1) 不会中断操作，语句继续执行。必须满足两个条件才能真正阻止：
- 错误级别 ≥ 16（例如
RAISERROR('禁止删除索引', 16, 1)） - 确保外层没有
TRY...CATCH吞掉该错误；若运维脚本自己包了TRY，需约定错误码并检查@@ERROR
别在触发器里做耗时操作：比如 JOIN 百万行日志表查操作人，或调用链接服务器。这会让所有 DROP INDEX 请求卡住，连带阻塞其他 DDL 操作。
最易被忽略的一点：DDL 触发器本身不参与用户事务——RAISERROR 报错后，当前 DDL 语句回滚，但不会影响之前已提交的任何用户事务。这点和 DML 触发器行为不同，务必在测试中验证实际拦截效果。
