表结构演进需遵循不阻塞、可回滚、有验证原则：加字段优先用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 + 应用读写链路，比任何文档都管用。
