17370845950

表结构演进需遵循不阻塞、可回滚、有验证原则：加字段优先用ONLINE DDL，删字段或改类型

须双写灰度迁移，索引变更需先从库观察并用pt-online-schema-change等工具，所有DDL必须配版本化SQL、回滚脚本及影子库验证。

表结构演进本身不危险，危险的是变更方式和时机。核心原则是：不阻塞、可回滚、有验证。

加字段优先用 ONLINE DDL（尤其 MySQL 5.6+）

避免锁表导致查询超时或写入堆积。例如添加非空字段且无默认值会全表扫描并锁表；应改为：

• 先加允许 NULL 的字段（不触发重建）
• 用异步任务批量补默认值（不影响线上）
• 再通过 ALTER TABLE ... MODIFY COLUMN ... NOT NULL 改约束（仍需评估锁粒度）

删字段/改类型必须走双写+灰度迁移

直接 DROP COLUMN 或修改列类型（如 VARCHAR(255) → VARCHAR(50)）可能引发应用报错或数据截断。稳妥做法是：

• 新增兼容字段（如 user_name_v2），应用双写旧字段和新字段
• 离线校验新旧字段一致性（抽样比对、全量 checksum）
• 切读到新字段，确认无误后下线旧字段

索引变更要先观察再操作

新建索引看似安全，但大表上仍可能引发 I/O 压力或复制延迟；删除索引则可能让慢查询突然爆发。建议：

• 在从库上先建索引，观察复制延迟和 CPU/IO 情况
• 使用 pt-online-schema-change 或 gh-ost 替代原生命令（支持暂停、限速、自动回滚）
• 上线前查 EXPLAIN 和慢日志，确认新索引被实际命中

所有变更必须配套版本化 SQL + 回滚脚本

禁止手工执行 ALTER，每个上线变更需包含：

• 正向 SQL（含注释说明影响范围和预期耗时）
• 对应回滚 SQL（如 ADD COLUMN → DROP COLUMN；NOT NULL → NULL）
• 验证语句（如 SELECT COUNT(*) FROM t WHERE new_col IS NULL）
• 纳入发布流程，与应用版本绑定，失败自动触发回滚

不复杂但容易忽略：每次变更前，在影子库或预发环境完整跑一遍 DDL + 应用读写链路，比任何文档都管用。