gh-ost能绕过锁表，因其不依赖MySQL原生DDL，而是通过创建影子表、分块拷贝数据、实时解析并重放binlog增量变更来实现在线字符集转换，全程原表可读写。
不能直接用 ALTER TABLE ... CONVERT TO CHARACTER SET，它会锁表，哪怕只改字符集，对百万级以上表也等于停服。
为什么 gh-ost 能绕过锁表
它不依赖 MySQL 原生 DDL 流程，而是用“影子表 + binlog 解析 + 行级重放”的方式模拟变更：先建一个带新字符集的空表（_t_gho），再逐块拷贝数据，同时监听原表 binlog，把拷贝期间产生的增删改实时同步过去。整个过程原表始终可读可写。
和 pt-online-schema-change 不同，gh-ost 不依赖触发器，因此能兼容已存在触发器的表；它也不 require SUPER 权限（只需 REPLICATION SLAVE 和 REPLICATION CLIENT）；更重要的是，它能精确控制 chunk 大小和暂停时机，对业务抖动更可控。
- 必须开启 binlog，且格式为
ROW（binlog_format=ROW） - 原表必须有主键或唯一非空索引，否则无法准确定位行做同步
- 不支持
ENUM/SET字段的字符集隐式转换，需显式指定列级CONVERT - 目标字符集（如
utf8mb4）必须已在服务器配置中启用（character-set-server=utf8mb4），否则建影子表会失败
执行前必须检查的 4 个配置项
漏掉任一都会导致 gh-ost 启动失败或中途退出：
-
my.cnf中[mysqld]段必须含：log-bin、binlog-format=ROW、server-id=非0整数 - 确认用户权限：
SELECT, INSERT, DELETE, UPDATE, SUPER, REPLICATION SLAVE, REPLICATION CLIENT（SUPER仅用于初始连接时查变量，非全程必需） - 运行
SHOW VARIABLES LIKE 'collation_server';，确保不是utf8mb4_0900_as_cs（MySQL 8.0.17+ 默认）——该排序规则与旧应用不兼容，建议显式指定utf8mb4_unicode_ci或utf8mb4_general_ci - 检查表中是否存在
TEXT/BLOB列：若要保留完整长度，需在--alter中显式加MODIFY COLUMN语句，否则gh-ost默认按原定义重建，可能丢失utf8mb4下的 4 字节扩展能力
实际执行命令与关键参数说明
以将 users 表从 utf8 升级为 utf8mb4 为例：
gh-ost \ --host=10.0.1.100 \ --user="ghost" \ --password="xxx" \ --database="app_db" \ --table="users" \ --alter="CONVERT TO CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci" \ --chunk-size=1000 \ --max-load="Threads_running=25" \ --critical-load="Threads_running=50" \ --throttle-control-replicas="10.0.1.101:3306" \ --allow-on-master \ --assume-rbr \ --verbose \ --initially-drop-ghost-table \ --initially-drop-old-table \ --execute
-
--allow-on-master：允许直接在主库操作（默认只允许在从库） -
--assume-rbr：跳过 binlog 格式校验（确保你已人工确认是 ROW） -
--chunk-size=1000：每批复制 1000 行，避免单次事务过大；若主键跨度大，可加--max-lag-millis=1500控制延迟 -
--throttle-control-replicas：指定监控某从库延迟，一旦延迟超阈值自动暂停，防止拖垮从库 -
--initially-drop-*：清理残留的临时表名，避免因上次中断遗留的_users_gho冲突
切换瞬间最容易被忽略的 3 个点
当 gh-ost 输出 2026/05/07 14:02:18 Copied 12345678 rows. Elapsed: 3h22m11s. Est. remaining: 0s. 并开始 rename 时，真正的风险才刚出现：
- rename 是原子操作，但之后旧表立刻变为
_users_del，此时若有未完成的长事务还在读旧表别名（比如某些 ORM 缓存了表名），会报Table doesn't exist - 外键约束不会自动迁移，如果该表被其他表的外键引用，必须提前用
ALTER TABLE ... DROP FOREIGN KEY+ADD FOREIGN KEY手动重建指向新表 - 应用层连接池可能缓存了旧表的元数据（如列类型长度），尤其 Java 的
mysql-connector-java在cachePrepStmts=true时，需重启连接池或执行FLUSH TABLES强制刷新
真正难的从来不是工具跑起来，而是 rename 那一秒之后，所有依赖这张表的链路是否还稳。
