sql server默认不记录ddl操作历史，需显式启用审计功能或ddl触发器；推荐使用sql server audit结合文件或windows事件日志，并注意权限配置与日志轮转管理。
SQL Server 本身不自动记录“谁改了表结构”这种操作到系统视图里——sys.tables、sys.columns 这些只存当前状态，不存变更历史。 想审计 DDL（比如 ALTER TABLE、DROP COLUMN），必须主动启用日志能力。
SQL Server 审计功能必须显式开启才能捕获 DDL 事件
默认情况下，SQL Server 不保存任何 DDL 操作记录。你得手动配置服务器级或数据库级的 AUDIT 对象，并绑定到 SERVER_OBJECT_CHANGE_GROUP 或 DATABASE_OBJECT_CHANGE_GROUP 这类审计组。
- 只开
SELECT权限的账号执行ALTER TABLE？它不会出现在sys.dm_exec_sessions历史里——那个视图只反映当前会话 -
fn_dblog()和sys.fn_dblog不可靠：事务日志不是审计日志，没用户上下文，且会被截断，不能当审计依据 - 用
sp_who2或sys.dm_exec_requests查“正在执行”的语句？它们只看当前运行态，改完就没了
替代方案：用 DDL 触发器抓取关键操作（轻量但需注意权限）
如果暂时无法配审计策略，可建一个数据库级 DDL 触发器，把 ALTER_TABLE、DROP_TABLE 等事件写入自定义日志表。它比审计功能更灵活，但有两点硬限制：
- 触发器本身不能跨数据库写日志（除非用
EXEC('INSERT ...') AT [linked_server]，但太重） - 触发器执行失败会导致原 DDL 失败（比如日志表满、权限不足），所以日志表必须高可用、带
TRY...CATCH包裹插入逻辑 - 触发器中可用
EVENTDATA()提取login_name、post_time、tsql_command，但拿不到客户端 IP——得靠host_name或结合sys.dm_exec_connections关联（仅限当时在线会话）
最稳路径：用 SQL Server Audit + Windows Event Log 或二进制文件落地
生产环境唯一推荐的方式。步骤很明确：
- 先建服务器审核目标：
CREATE SERVER AUDIT [DDL_Audit] TO FILE (FILEPATH = 'D:\Audit\') - 再建数据库审核规范：
CREATE DATABASE AUDIT SPECIFICATION [DDL_Spec] FOR SERVER AUDIT [DDL_Audit] ADD (DATABASE_OBJECT_CHANGE_GROUP) - 启动两者：
ALTER SERVER AUDIT [DDL_Audit] STATE = ON；ALTER DATABASE AUDIT SPECIFICATION [DDL_Spec] STATE = ON - 查结果用：
SELECT * FROM sys.fn_get_audit_file('D:\Audit\*.sqlaudit', DEFAULT, DEFAULT)—— 返回含server_principal_name、statement、object_name的完整记录
注意：审计文件默认按大小轮转，别等磁盘爆了才发现日志被覆盖；OBJECT_NAME 字段在改列时可能为空（因为 ALTER COLUMN 被归为“对象变更”，但不显式标出列名），得结合 statement 字段正则解析。
真正容易被忽略的是权限链：哪怕你开了审计，如果执行 ALTER TABLE 的账号是 db_owner 但没被显式授 VIEW SERVER STATE，它的操作仍可能不进审计——SQL Server 审计对高权限账号有静默豁免倾向，必须验证实际日志是否真包含该账号的操作。
