表结构不一致必然导致SQL线程中断，主库执行依赖新字段的操作时从库报ERROR 1054或1146；需用mysqldump --no-data导出结构并diff比对，修复前必须停从库复制、避开主库写入、执行后验证字段定义完全一致。
表结构不一致会直接导致SQL线程报错中断，不是“可能出问题”，而是“必然失败”——只要主库执行一条依赖新字段或索引的操作，从库就会卡在ERROR 1054或ERROR 1146上。
为什么ERROR 1054一出现就说明结构已不同步
这个错误本质是SQL线程在解析binlog事件时，发现语句里引用的列（比如new_col）在从库表中根本不存在。MySQL不会提前校验表结构，只有真正执行到那条UPDATE/INSERT时才报错。
- 常见触发场景：主库加了
ALTER TABLE ADD COLUMN，但从库没同步执行；或者主库用SET sql_log_bin = 0跳过记录，人工在主库改了结构却忘了同步从库 - 注意
Seconds_Behind_Master可能还是0或NULL——这不是延迟，是SQL线程已停，只是没及时刷新状态 - 别信
SHOW CREATE TABLE肉眼比对：字段顺序、默认值、字符集、COLUMN_FORMAT、甚至注释差异都可能导致复制失败（尤其在MySQL 8.0+严格模式下）
用mysqldump --no-data快速比对结构差异
这是最轻量、最可靠的一线排查方式，不依赖额外工具，也不影响运行中的复制。
- 主库导出：
mysqldump -h master_ip -u user -p --no-data --skip-triggers --databases db_name table_name > master_struct.sql - 从库导出：
mysqldump -h slave_ip -u user -p --no-data --skip-triggers --databases db_name table_name > slave_struct.sql - 本地执行：
diff master_struct.sql slave_struct.sql，重点关注CREATE TABLE块里的字段定义、ENGINE、CHARSET、COLLATE、索引和约束声明 - 必须加
--skip-triggers和--no-data，否则可能混入触发器或自增值干扰判断
安全修复结构不一致的三个硬性条件
直接在从库执行ALTER TABLE是最常用做法，但跳过以下任一条件，都可能引发二次复制中断或数据错乱。
- 主库对该表当前无写入：要么业务低峰期操作，要么临时在主库加
FLUSH TABLES WITH READ LOCK（几秒即可），避免ALTER被复制到从库后与正在执行的DML冲突 - 从库先停复制：
STOP SLAVE;——否则ALTER会被复制回主库（如果开启log_slave_updates），形成环路 - 执行完立刻验证：
SHOW CREATE TABLE确认字段名、类型、默认值、是否NOT NULL等全部一致；再查SELECT COUNT(*) FROM information_schema.COLUMNS核对字段总数 - 重启复制后盯住
Seconds_Behind_Master回落速度，若持续为NULL或暴涨，说明ALTER本身有隐性问题（如字段类型不兼容现有数据）
pt-table-checksum能发现结构不一致吗
不能直接报“结构不一致”，但它会在校验阶段因结构差异而报ERRORS非零，提示你去查问题根源。
- 当
pt-table-checksum扫描某张表时，若主从字段数不同、主键缺失、或某列类型不支持校验（如JSON在旧版本），它会跳过该表并记入ERRORS列 - 输出里看到
DIGEST为空、DIFFS为0但ERRORS为1，基本可断定是结构层面不兼容，不是数据内容差异 - 此时别急着跑
pt-table-sync，先回到结构比对步骤——工具不会替你做决策，只会暴露它无法处理的问题
结构不一致的修复，核心不是“怎么改”，而是“什么时候改、在哪台机器上改、改完怎么验”。哪怕只差一个DEFAULT值，也可能让后续所有基于该字段的UPDATE都失败。别省那几秒钟的SHOW CREATE TABLE比对，也别信“应该一样”的直觉。
