MySQL表结构变更无法被PHP主动监听，因DDL操作在服务端执行且无事件机制；可行方案是通过迁移脚本主动上报，或约束ALTER操作写入日志表供定时消费。
MySQL 表结构变更无法被 PHP 主动监听
PHP 本身没有机制能“监听”ALTER TABLE 这类 DDL 操作。数据库字段变更（比如加列、改类型、删列）发生在 MySQL Server 层，不经过应用层，更不会触发 PHP 的任何钩子或事件。
常见错误现象是试图在 Laravel 或原生 PDO 中注册回调、监听 information_schema.COLUMNS 变化，或者轮询 SHOW COLUMNS —— 这些要么无效，要么高开销、有延迟、漏变更。
真正可行的路径只有一条：把“字段变更”这个动作，从被动监听转为主动上报。
用 migration 脚本显式触发业务逻辑
如果你用的是 Laravel、Symfony 或自研的迁移系统，php artisan migrate 或类似命令执行时，才是你唯一可控的“字段变更发生时刻”。这时可以插入业务逻辑。
立即学习“PHP免费学习笔记（深入）”；
实操建议：
- 在 migration 文件的
up()方法末尾，调用一个封装好的通知函数，比如triggerColumnChangeNotification('users', 'email', 'added') - 该函数可写入日志、发消息到 Redis Channel、调用 Webhook、更新配置中心标记位
- 避免在
up()里直接做耗时操作（如 HTTP 请求），优先走异步队列，比如dispatch(new HandleColumnChangeJob(...)) - 注意 rollback 场景：
down()也要对称处理，否则状态不一致
用触发器 + 通用日志表间接捕获列级变更
MySQL 触发器不能监听 DDL，但你可以约定：所有字段变更必须通过一个统一入口脚本执行，该脚本在 ALTER TABLE 前后写入一张 schema_change_log 表。
示例结构：
CREATE TABLE schema_change_log (
id BIGINT PRIMARY KEY AUTO_INCREMENT,
table_name VARCHAR(64),
column_name VARCHAR(64),
operation ENUM('add', 'drop', 'modify'),
data_type VARCHAR(64),
executed_at DATETIME DEFAULT CURRENT_TIMESTAMP
);
PHP 应用可通过定时任务（如每分钟查一次 schema_change_log WHERE processed = 0）来消费变更。关键点：
- 必须靠流程约束，不是技术强制 —— DBA 或运维绕过脚本直连执行
ALTER就会丢失记录 -
information_schema.COLUMNS的DATA_TYPE字段不包含长度/精度（如VARCHAR(255)只存VARCHAR），需额外解析COLUMN_TYPE - 不要用
SELECT ... FOR UPDATE锁整表，用UPDATE schema_change_log SET processed = 1 WHERE id = ?做幂等消费
监听数据变更 ≠ 监听结构变更
有人混淆了“某列值变了”和“这张表多了个列”。前者可用 MySQL Binlog + maxwell 或 canal 捕获；后者完全不在 Binlog 记录范围内（DDL 默认不写 row 格式 binlog，且即使开启也只记语句，不解析影响的列）。
如果硬要实时感知，唯一接近的方式是：
- 开启 MySQL general_log（仅调试！性能杀器），过滤
ALTER/CREATE关键字 - 用
tail -f+grep实时扫日志文件，再由 PHP 进程接收信号或轮询临时标记文件 - 这方法线上禁用：general_log 开启后 QPS 掉 30%+，且日志格式不稳定，MySQL 版本一升级就可能崩解析逻辑
真正上线的系统，几乎都放弃“自动发现结构变更”，转而靠迁移流程卡点 + 配置中心登记 + 上线前人工核对 DESCRIBE table_name 输出。
