ALTER TABLE 直接修改列定义在生产环境极危险，因多数数据库会锁表导致读写阻塞，千万级表操作可能持续数分钟，引发超时、连接池打满及雪崩；pt-osc 通过影子表+触发器+增量同步实现在线变更，gh-ost 则基于 binlog 解析，对主库影响更小。
ALTER TABLE 直接修改列定义为什么在生产环境很危险
因为大多数数据库（如 MySQL 5.7 及更早版本、PostgreSQL 的某些 ALTER COLUMN 操作）执行 ALTER TABLE ... MODIFY COLUMN 或 ALTER TABLE ... CHANGE COLUMN 时会锁表，期间所有读写请求都会阻塞。哪怕只改一个 VARCHAR(255) 到 VARCHAR(500)，如果表有千万级行，操作可能持续数分钟甚至更久，导致服务超时、连接池打满、下游重试雪崩。
常见错误现象包括：Lock wait timeout exceeded、应用日志中大量 Waiting for table metadata lock、监控里 QPS 突降至零。
不是所有“加长度”都安全：MySQL 8.0+ 对部分 DDL 支持 ALGORITHM=INSTANT，但仅限于添加列、重命名列等极少数操作；修改列类型（如 TINYINT → INT）、调整字符集、增减 NOT NULL 约束仍需拷表或重建索引。
pt-online-schema-change 是什么，它怎么避开锁表
pt-online-schema-change（简称 pt-osc）是 Percona Toolkit 提供的成熟在线 DDL 工具，核心思路是“影子表 + 触发器 + 增量同步”，不依赖数据库原生在线能力。
它的工作流程是：
- 创建一个结构变更后的新表（影子表），比如把
user_name VARCHAR(255)改成VARCHAR(500) - 在原表上建
INSERT/UPDATE/DELETE三类触发器，捕获变更并同步到影子表 - 分批次把原表数据拷贝到影子表（每次
--chunk-size控制，避免单次事务过大） - 拷完后原子切换：
RENAME TABLE t TO t_old, t_new TO t
关键参数建议：
-
--alter "MODIFY COLUMN user_name VARCHAR(500)"：必须用标准 SQL 语法，不能带引擎或注释 -
--chunk-size 1000：根据单行大小和主键分布调小，避免长事务拖慢主库 binlog -
--max-load="Threads_running=25"：CPU 或连接数超阈值时自动暂停 -
--critical-load="Threads_running=50"：达到该值直接退出，防止恶化
注意：触发器本身有开销，大流量写入场景下可能轻微增加延迟；且要求原表必须有主键或唯一非空索引，否则无法分块。
gh-ost 和 pt-osc 选哪个
gh-ost（GitHub Online Schema Migrations）用的是“binlog 解析 + 模拟从库写入”方式，不依赖触发器，因此对主库影响更小，尤其适合高并发写入场景。
但它需要额外配置 binlog 格式为 ROW，且必须开启 log_slave_updates（即使单实例也要设）；另外不支持外键约束的表，会直接报错退出。
对比要点：
- 锁风险：
gh-ost全程无触发器，主库写入几乎无感知；pt-osc触发器在高写入下可能成为瓶颈 - 兼容性：
pt-osc支持 MySQL 5.1+，gh-ost要求 MySQL 5.6+ 且 ROW binlog - 回滚成本：
gh-ost切换前可随时kill进程中断，残留影子表自动清理；pt-osc中断后需手动删触发器和临时表 - DDL 类型限制：两者都不支持修改分区定义、全文索引等复杂操作
如果你的 MySQL 是 5.7+、已配好 ROW binlog，优先用 gh-ost；否则 pt-osc 更稳妥。
上线前必须验证的三个细节
工具再稳，也掩盖不了人为疏漏。这些点容易被跳过，却常导致线上事故：
- 确认目标列当前没有被应用层做长度校验（比如 Java 代码里写了
if (name.length() > 255) throw），否则扩宽字段后业务逻辑可能出错 - 检查该列是否出现在任何函数索引、生成列、JSON_EXTRACT 表达式中——这类依赖在
gh-ost切换后可能失效 - 提前在从库上跑一遍相同命令加
--dry-run（pt-osc）或--test-on-replica（gh-ost），观察复制延迟是否突增、是否有警告日志如Column type mismatch
最常被忽略的是字符集隐式转换：比如把 VARCHAR(255) CHARACTER SET utf8 改成 utf8mb4，会导致索引长度超限（utf8mb4 最多占 4 字节），必须同步调整 innodb_large_prefix 和 ROW_FORMAT=DYNAMIC，否则切换瞬间会失败。
