导航：首页 > 互联网科技 >

MYSQL 修改表结构 gh-ost

发表于：2026-10-31 作者：千家信息网编辑

千家信息网最后更新 2026年10月31日，本篇内容主要讲解"MYSQL 修改表结构 gh-ost "，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习"MYSQL 修改表结构 gh-ost "吧!PT工具

千家信息网最后更新 2026年10月31日MYSQL 修改表结构 gh-ost

本篇内容主要讲解"MYSQL 修改表结构 gh-ost "，感兴趣的朋友不妨来看看。本文介绍的方法操作简单快捷，实用性强。下面就让小编来带大家学习"MYSQL 修改表结构 gh-ost "吧!

PT工具在MYSQL中的使用其实已经好像有"半个世纪了"，其出名的原因主要是因为pt-osc，如果你不知道，那你真的用过MYSQL，其实还有另外两家 FB-OST , GH-OST.

实际上PT-OSC 虽然使用了这么多年，他也存在一些问题

PT-OSC

1 有些操作中，会引起高负载的写操作

2 在原表和新表切换的过程中更名，可能有失败的可能（虽然这样的情况不多，但可能存在）

3 要求多，主键（具有唯一性的），表有外键的时候需要添加参数，并且很可能还是有问题，可能会导致主从延迟，表中不建议由其他trigger ，PTOSC使用的就是 update , insert , delete triggers 来解决原表和新表之间的数据同步的问题。

4 对于大表，主业务表，还是不敢再业务时间来做，也是要到非业务或低峰期，来做。

虽然有这么多那么多的问题，但也是用了很多年。FB-OST 没有研究但原理也是类似的。（FB-OST）

GH-OST 其实是这三者里面，原理不一样的，有点开脑洞，开发者是一个DBA,拥有15年的经验。

以下为开发者，在GITHUB 大会上的自我介绍

在考虑上面两个工具的缺点后，我使用了binary log ，虽然也我这里面也收到了FB-OST 的启发，但我这里的设计比上面提到的工具的优点，主要就是我的新表的数据来源不是来自于tigger 而是来自于binlong。大家可以想一下，如果我同事更改15个表，要产生多少trigger，多少了connections 要被消耗，系统的工作负载会非常的重，MYSQL 不喜欢这样，而使用了binlog他不管修改多少表，他对于MYSQL 来说就是一个序列化的事情，MYSQL 喜欢序列化的事情，这样不会对系统产生更多的负载。

总结使用BINOG 有以下的优点

1 binlary logs 可以从任意的地方来读取，GH-OST 相当于一个从节点

2 gh-ost 控制了整个数据流，避免突然的无法控制的增量写

3 gh-ost 已经与master 节点工作负载解耦

4 gh-ost 的设计是依照顺序写的原则，完全避免了锁，对于操作的

server 来说就是一个single connection

5 数据的增量计算方法简单

上面的三个图很好的诠释了gh-ost 为什么比其他的工具要强的原因，可以从从库来读取数据，在写到master ，我也可以在master 上读，然后在master 上写，还可以在slave 上读，在slave 上改。

并且gh-ost还可以做真实的测试，而不是dry-run

另外一个优点是GH-OST 在执行的时候，可以根据master的状态来停止正在执行的任务，而等到master的负载变得正常后，在根据BINLOG继续来处理之前的延迟的工作。所以GH-OST 是一个安全的，值得信任的工具。

（完）

------------------------------

当然，这个工具也很具有中国的特色

-------------------------------


要使用这个工具本身要本身的MYSQL是一定要支持binlog，必须打开



log-bin=mysql-bin

binlog-format=ROW

log-slave-updates=ON


下面是一个小的实验



gh-ost -allow-on-master -assume-rbr -exact-rowcount


-critical-load Threads_running=400 -critical-load-hibernate-seconds 60


-database employees -max-load Threads_running=100


-nice-ratio 0.1  -chunk-size 5000 -ask-pass -table employeess


-user ghost -host 192.168.198.81


-alter 'add COLUMN add_column varchar(2000)'


-verbose -execute 2>&1 | tee gh-ost.log

添加一个大字段是没有问题的。

在程序里面，下面这段是从binlog 中将需要同步的 U D I 操作进行挑拣

创建隐藏的魔鬼表

通过阅读部分源码，这里密码的insert 是采用 insert DUPLICATE KEY 方式来进行数据的插入。

其实从设计上来想，作者的想法是很有意思的，因为拷贝原表的数据到结束的这段时间，是不能应用这段时间的在这个表的修改，但BINLOG 里面是可以记录百分之百的对这张表的数据的变动的记录，则只要从开始拷贝表的时间点开始，到结束拷贝后，在将binlog 里面的数据进行提取，然后在新表上操作，待完成后在更换两个表rename，达到与原来加trigger的目的一样的效果。利用BINLOG的顺序性，稳定性，准确性等特点，将trigger性能问题化解。

另外更有意思的是gh-ost 可以在程序操作的过程中，修改一些配置

例如上例子中的,可以用下面的例子，将一些参数打入到正在运行的命令中

echo 'dml-batch-size=100' | nc -U /tmp/gh-ost.employees.employeess.sock

最后说说几个重要的参数

-allow-master-master 在主库中运行

-allow-nullable-unique-key 如果是表中唯一索引是不允许有NULL得情况，这里如果情况存在，则给这个值，程序可以继续运行

-assume-master-host string 当你目前的情况事主主的情况，

-assume-rbr 设置此标志可避免重新启动复制，并且您可以继续使用gh-ost而无需超级特权

-chunk-size int 每次要处理的行数

-concurrent-rowcount 计算需要copy的行

-critical-load 设置最大的阈值

-critical-load-hibernate-seconds 当达到负荷值后，系统将停止操作多少秒