MySQL存储过程不能自动发现表结构变更，需依赖外部调度定期扫描information_schema并比对哈希快照，结合general_log或PERFORMANCE_SCHEMA补全操作溯源。
MySQL存储过程能自动发现表结构变更吗
不能直接感知，必须靠人工触发或定时调用。MySQL 存储过程本身不监听 CREATE TABLE、ALTER TABLE 这类 DDL 事件——它没内置的 DDL 触发器机制。想“自动化”，得把存储过程挂到外部调度上（比如 mysql_event 或系统 cron），定期扫描 information_schema 对比快照。
怎么用存储过程对比两次表结构差异
核心是查 information_schema.COLUMNS 和 information_schema.TABLES，把关键字段导出为字符串哈希，再做集合差。常见错误是只比列名，漏掉 DATA_TYPE、IS_NULLABLE、COLUMN_DEFAULT、EXTRA 这些实际影响语义的项。
- 每次扫描前先存快照：往审计表里插一行
SELECT CONCAT(table_schema, '.', table_name), MD5(GROUP_CONCAT(... ORDER BY ordinal_position))的结果 - 对比时用
LEFT JOIN找出新增/删除的表，再对同名表用GROUP_CONCAT拼接列定义做 MD5 比较 - 别用
SELECT * FROM COLUMNS直接比——ORDINAL_POSITION可能因 MySQL 版本不同而错位，必须显式按顺序拼接 - 注意
information_schema查询本身不加锁，但高并发下可能读到中间状态；建议在低峰期跑或加SET SESSION TRANSACTION ISOLATION LEVEL READ COMMITTED
存储过程里怎么安全记录结构变更日志
审计表必须独立于业务库，且结构极简：只存 event_time、schema_name、table_name、change_type（ADD/DROP/MODIFY）、diff_summary（TEXT 字段，存 JSON 或纯文本描述），绝不存原始 COLUMNS 全量数据——否则单次 ALTER 就写几 MB 日志。
- 插入前用
INSERT IGNORE或ON DUPLICATE KEY UPDATE防重复，主键设为(schema_name, table_name, event_time)组合 -
diff_summary别拼超长 SQL，推荐格式如：{"added": ["col_x INT"], "dropped": ["col_y VARCHAR(20)"], "modified": {"col_z": "VARCHAR(50) → TEXT"}} - 避免在存储过程中调用
sys_exec()或写文件——多数生产环境禁用，且跨平台不可靠 - 如果要标记操作人，
USER()返回的是连接账号，不是发起 DDL 的应用用户；真要溯源得靠代理层（如 ProxySQL）或应用层传参
为什么不能只靠存储过程完成全链路结构审计
因为存储过程无法捕获“谁在什么时间发了哪条 DDL”这个关键事实。MySQL 的 general_log 能记 ALTER TABLE 语句和用户，但没结构语义；binlog 有变更但无原始语句；企业版 audit_log 插件虽能记录 DDL，但输出是 XML/JSON 文件，没法直接喂给存储过程处理。
真正落地时，存储过程只是“结构快照比对”这一环，必须配合：外部定时任务拉取 general_log 中的 DDL 行、解析后入库；或者用 PERFORMANCE_SCHEMA 的 events_statements_history_long 查最近的 DDL（需开启相关 consumers）；再把结果喂给你的存储过程做归并分析。漏掉任何一环，就只剩“发现了变化”，却不知道“谁干的、为什么干”。
