能，Canal通过解析Binlog中的QueryEvent捕获ALTER TABLE ADD COLUMN等DDL语句，并依赖TableMeta组件（如DatabaseTableMeta）持久化更新表结构，确保后续DML按新字段正确解析。
Canal能自动识别ALTER TABLE ADD COLUMN吗？
能，但前提是配置了正确的元数据管理组件，且MySQL Binlog格式为ROW、binlog_row_image=FULL。Canal本身不“主动监听DDL”，而是靠解析Binlog里的QueryEvent（含DDL语句）来触发元数据更新。如果用了默认的MemoryTableMeta，它会在收到ALTER TABLE事件后立即重构建表结构，后续的WriteRowsEvent就能按新字段解析——但这只在服务未重启时有效。
为什么加完字段后Canal消费端报“Column not found”？
常见于以下几种情况：
- 没开
binlog_format=ROW或binlog_row_image=MINIMAL：DDL能捕获，但后续INSERT/UPDATE的行数据不带新增字段值 - Canal instance配置里
canal.instance.filter.regex过滤太严，把information_schema或mysql库的DDL事件拦掉了（某些DDL会先写系统表） - 用了
MemoryTableMeta但Canal Server中途重启：内存元数据丢失，恢复后仍按旧结构解析新数据 - DDL执行时Canal正处在拉取间隙（比如
batchSize=1000，而DDL夹在第999和1000条之间），导致部分事件被跳过
如何让元数据变更真正可靠持久？
必须切换到DatabaseTableMeta实现，否则线上无法兜底。它的核心逻辑是把每次ALTER解析出的表结构快照存进本地MySQL（或指定DB），并在find()时按timestamp或binlog position查对应版本。配置要点：
- 在
instance.properties中显式指定：canal.instance.tsdb.spring.xml=classpath:spring/tsdb/jdbc-tsdb.xml - 确保
jdbc-tsdb.xml里url/username/password可连通，且目标库已执行canal/tsdb/sql/create_table.sql建表 -
apply()方法内部会对DDL做语法校验（比如是否含ADD COLUMN），非法语句会被丢弃并打WARN日志，需人工检查 - 上线前务必用
canal-admin或curl调/api/v1/instances/{id}/meta确认当前元数据版本与MySQL实际一致
加字段后下游Flink/Spark消费失败怎么办？
Canal JSON输出里data数组字段顺序和mysqlType键名严格对齐，但Flink CDC connector默认按字段名映射，不依赖顺序。真正容易崩的是手写RowData解析逻辑：
- 别硬编码
row.getField(3)取weight，改用row.getField("weight") - 如果用
CanalJsonDeserializationSchema，确保ignoreParseErrors = true，否则缺失字段直接抛JsonParseException - UPDATE事件的
old字段只包含被修改前的列，新加字段不会出现在old里——这是正常行为，不是bug
最麻烦的其实是DDL和DML事件的时间差：ALTER执行完，业务立刻INSERT带新字段的数据，但Canal可能还没完成元数据apply（尤其在DatabaseTableMeta下要写DB+刷缓存）。这时建议在应用层加一个轻量级等待机制，比如轮询/api/v1/instances/{id}/status直到tsdbVersion更新。
