Azure SQL：如何判断表是否被创建/修改及操作人

针对你团队遇到的这个头疼问题——其他团队私自对Azure SQL DB做DDL操作（建表、改表、修改存储过程），没走协调流程，导致版本控制缺失、搭本地库或恢复备份时因引用缺失报错，下面分享几个适合Azure SQL的非实时程序化解决方案，结合你的需求逐一拆解：

方案1：定期快照系统目录视图并对比 #

这是你提到的思路，完全可行，落地成本也低，具体可以这么做：

• 核心要快照的系统视图：
  • sys.tables：追踪表的创建/修改时间、所有者信息
  • sys.procedures：追踪存储过程的修改时间、定义内容
  • sys.columns：追踪表结构的字段变更（新增、删除、数据类型修改）
• 实现步骤：
  1. 建一个专门的审计表（比如dbo.SchemaChangeSnapshot），存每次快照的时间戳、对象类型、对象名、修改时间、所有者等字段。
  2. 定期（比如每天凌晨）跑脚本，把当前sys视图的状态插入到审计表。
  3. 写对比逻辑找差异：
     • 对比sys.tables的modify_date，如果最新快照的时间比上一次新，说明表被修改；
     • 用HASHBYTES('SHA2_256', definition)生成存储过程定义的哈希值，对比前后哈希值变化判断是否被修改；
• 优缺点：
  • ✅ 纯SQL脚本就能实现，不用额外Azure服务，适合非实时场景
  • ❌ 没法直接拿到具体操作人，只能看到对象的owner，如果操作人用的是共享账户，就没法精准追踪
  • ❌ 只能知道对象变了，但不知道具体改了什么（比如是加了字段还是改了主键）

方案2：利用Azure SQL审计功能（最推荐） #

Azure SQL的审计功能专门用来记录数据库级操作，包括所有DDL语句，能直接拿到操作人、操作时间、执行的SQL语句，完美解决你的痛点：

• 配置审计：
  1. 在Azure门户找到你的SQL DB，进入「安全性」→「审计」，开启审计，把日志存到Azure存储账户或Log Analytics工作区。
  2. 配置审计策略时，勾选SCHEMA_OBJECT_CREATE_GROUP、SCHEMA_OBJECT_ALTER_GROUP、SCHEMA_OBJECT_DROP_GROUP这些DDL事件组，它们会记录所有建表、改表、删表、修改存储过程的操作。
• 程序化读取审计日志：
  • 如果存在Blob：用PowerShell、Python或Azure Function定期读取Blob里的审计日志（是JSON格式，不是你说的二进制！之前可能误解了），解析里面的event_time（操作时间）、session_server_principal_name（操作人）、statement（执行的SQL语句）。
  • 如果存在Log Analytics：用Kusto查询定期查AzureDiagnostics表，筛选Category为SQLSecurityAuditEvents、action_name包含ALTER_TABLE/CREATE_TABLE/ALTER_PROCEDURE的记录，直接提取关键信息。
• 优缺点：
  • ✅ 能精准拿到操作人、具体SQL语句、操作时间，完全满足需求
  • ✅ 非实时场景下定期拉取日志即可，不用实时监控
  • ✅ 不用改数据库里的任何对象，无侵入性
  • ❌ 需要额外配置Azure存储或Log Analytics，有少量成本（但日志存储成本极低）

方案3：创建DDL触发器记录变更 #

如果不想依赖外部Azure服务，也可以在数据库里建DDL触发器，把所有DDL操作记录到自定义表，然后定期查询：

• 实现步骤：
  1. 建一个自定义审计表dbo.DDLChangeLog，字段包括ChangeID（主键）、ChangeTime、Operator、EventType、ObjectType、ObjectName、SQLStatement。
  2. 创建DDL触发器：

     CREATE TRIGGER TrackDDLChanges
     ON DATABASE
     FOR CREATE_TABLE, ALTER_TABLE, DROP_TABLE, CREATE_PROCEDURE, ALTER_PROCEDURE, DROP_PROCEDURE
     AS
     BEGIN
         SET NOCOUNT ON;
         INSERT INTO dbo.DDLChangeLog (ChangeTime, Operator, EventType, ObjectType, ObjectName, SQLStatement)
         VALUES (
             GETDATE(),
             SUSER_SNAME(),
             EVENTDATA().value('(/EVENT_INSTANCE/EventType)[1]', 'nvarchar(100)'),
             EVENTDATA().value('(/EVENT_INSTANCE/ObjectType)[1]', 'nvarchar(100)'),
             EVENTDATA().value('(/EVENT_INSTANCE/ObjectName)[1]', 'nvarchar(128)'),
             EVENTDATA().value('(/EVENT_INSTANCE/TSQLCommand/CommandText)[1]', 'nvarchar(max)')
         );
     END;
     

  3. 定期导出DDLChangeLog的数据，或者写脚本对比变更记录。
• 优缺点：
  • ✅ 能直接拿到操作人、具体SQL语句，不用依赖外部服务
  • ✅ 完全在数据库内部实现，适合不想用Azure服务的场景
  • ❌ 需要在数据库里建触发器和表，有一定侵入性
  • ❌ 如果触发器被禁用或删除，就会失去追踪能力，得确保只有你的团队有修改触发器的权限

总结建议 #

如果你的团队能接受用Azure服务，**方案2（Azure SQL审计）**是最优选择——无侵入性、信息完整，程序化读取也很方便；如果不想依赖外部服务，方案3（DDL触发器）是次优选择，能精准追踪变更细节；方案1适合快速实现，但没法拿到操作人信息，只能做基础的变更检测。

内容的提问来源于stack exchange，提问作者CubeRoot