高并发下，MySQL无锁变更，Online DDL和PT-OSC哪个更胜一筹？
- 内容介绍
- 文章标签
- 相关推荐
高并发下MySQL无锁变更，Online DDL和PT-OSC哪个更胜一筹？
哎呀，说到这个高并发下的MySQL变更，真的是一把辛酸泪啊！谁没在大半夜被叫起来修过数据库呢？那种感觉，简直了。今天咱们就来好好唠唠这个让人头秃的问题：到底是用原生的Online DDL，还是用老牌的PT-OSC？这不仅仅是个技术选型，简直就是一场赌博！赌赢了相安无事；赌输了那就是全站崩溃，老板拿着刀站在你身后，公正地讲...。
先说说 我们得明白一个事儿，无锁变更这四个字听起来很美，其实吧坑多着呢。很多人以为开了Online DDL就真的“Online”了业务完全不受影响，天真！太天真了，简直了。！
MySQL 5.6+的Online DDL：真的那么香吗？
MySQL 5.6开始支持Online DDL操作。在这之前,对表的修改会阻塞整个表的读写操作。 在5.6之后,可以使用ALTER TABLE语句的ALGORITHM和LOCK子句来控制DDL操作的各个方面。这些子句位于语句的末尾,通过逗号与表和列规范分开。比方说: ALTER TABLE tbl_name ADD PRIMARY KEY , ALGORITHM=INPLACE, LOCK=NONE; LOCK子句有助于微调对表的并发访问程度。
ALGORITHM子句主要用于性能比较,以及作为在遇到任何问题时回落到旧的表复制行为的备用方案。
听起来是不是很完美？ALGORITHM=INPLACE和LOCK=NONE参数实现“原地修改”，避免全表拷贝。但是兄弟们，别高兴得太早！这玩意儿限制一大堆，我懂了。！
比如你想加个索引， 那没问题，速度飞快：
ALTER TABLE user_order ADD INDEX idx_user_id , ALGORITHM=INPLACE, LOCK=NONE;
纯正。 但是一旦你要改列的类型，或者改字符集，嘿嘿，它立马就变脸了！它可能还是会去COPY表， 虽然它号称是Online的，但其实吧那个资源消耗，简直能把你的磁盘IO跑满。这时候，所谓的“无锁”就变成了“无限制”地占用资源！
到位。 文章浏览阅读4.3k次。_online ddl 什么是Online DDL ? 最新推荐文章于 2025-04-10 17:51:41 发布 原创于 2020-04-05 20:10:44 发布·4.3k 阅读·1 · ·CC 4.0 BY-SA版权版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明。 文章标签: #mysqlChenzxxxx关注点赞 踩 收藏 觉得还不错?一键收藏 评论 分享复制链接分享到 QQ分享到新浪微博扫一扫 举报举报online-DDL详细原理介绍及gh-ost讲解 jiaona_chen123的博客06-221万+ 1.MySQL onlineDDL各版本介绍 1.1onlineDDLinmysql5.5 在mysql5.5版本中已经增加了in-place方式,但依然会阻塞...
说白了就是... 你看，连官方文档都还是会锁表的，虽然时间很短，但在高并发下那一瞬间的锁表，就可能导致大量的线程堆积，像雪崩一样！
PT-OSC：老当益壮还是累赘？
再来说说PT-OSC。这可是个老古董了Percona Toolkit里的神器。PT-OSC通过影子表+触发器实现无锁变更。这原理听着就挺复杂的，对吧？
pt-osc 主要用于修改表时不锁表， 简单地说先说说创建一个与原始表一样的新的空表，并根据需要更改表结构，主要原因是是空表修改表结构速度会非常快，然后将原始表中的数据以小块形式复制到新表中， 我的看法是... 接着删除原始表，再说说将新表重命名为原始名称。在复制过程中， 对原始表的所有新的更改都将应用于新表，主要原因是在原始表上创建了一个触发器，以确保所有新的更改都将应用于新表。
坦白说... 这玩意儿的好处是稳！不管你什么DDL，它都能搞定，主要原因是它本质上是新建了一张表。但是坏处也显而易见：触发器！
如果你的业务写入量非常大，那个触发器简直就是性能杀手！每一条写入都要被触发器拦截，再同步到新表。 别担心... CPU直接爆炸，主从延迟也会让你怀疑人生。而且，它还要求表必须有主键，没主键？对不起，不伺候！
pt-online-schema-change --alter "MODIFY c VARCHAR NOT NULL DEFAULT ''" \ --user=admin --password=*** --host=127.0.0.1 --port=3306 \ --execute D=testdb,t=user_info --no-check-alter
你看这命令，参数多到让人眼花缭乱。一旦参数配错了 比如那个--chunk-size设得太大了磁盘IO瞬间被打满； 挽救一下。 设得太小了跑个DDL要跑到下个世纪去。这哪里是工具，简直是折磨！
场景大乱斗：谁才是真正的王者？
咱们来点实际的，看看具体场景下这两个货到底谁更胜一筹。
场景1：添加二级索引
奥利给！ 这种情况下Online DDL简直是吊打PT-OSC。为什么？主要原因是Online DDL添加索引是In-Place的，不需要全表拷贝，速度极快，而且几乎不锁表。你用PT-OSC的话，还得建个影子表，还得搞触发器，纯属脱裤子放屁——多此一举。
优势：无需重建表，仅修改元数据，允许并发DML操作。 代码语言：javascript，别担心...
但是 如果你是MySQL 5.6以前的版本，那不好意思，Online DDL要么不支持， 对，就这个意思。 要么支持得不好，这时候老老实实用PT-OSC吧，虽然慢点，但至少能跑。
场景2： VARCHAR列长度
这个就有点意思了。Online DDL支持，但是有条件！限制：VARCHAR列所需的长度字节数必须保持不变。0~255需要一个字节来编码值,大于等256需要两个字节来编码。使用In Place ALTER TABLE只支持将VARCHAR列大小从0到255字节增加，或从256字节增加到更大的大小。反之需要使用ALGORITHM=COPY才可以。
ALTER TABLE product MODIFY description VARCHAR, ALGORITHM=INPLACE, LOCK=NONE;
如果你不小心跨越了那个字节边界， Online DDL立马退化成COPY模式，那跟锁表也没什么两样了甚至更惨，主要原因是资源占用更高。 来日方长。 这时候， PT-OSC虽然笨重，但至少可控，你可以通过--max-load参数控制负载，别把数据库搞挂了。
场景3：修改列类型
这种情况下 Online DDL大体上是废了必须COPY表。这时候PT-OSC就成了救命稻草。虽然它也COPY表，但它是在后台偷偷地COPY， 栓Q！ 业务还能继续跑。而Online DDL一旦开始COPY，那个锁表的时间，可能会让你直接失业。
说明：需确保原表有主键，且新列允许NULL或指定默认值。 我无法认同... 场景：需一边添加索引并修改列类型。
那些年我们踩过的坑
说实话，这俩工具，谁也没比谁高贵多少。Online DDL虽然官方， 但是出的太晚了然后percona和 gh-ost等等开源产品已经大规模实践了,Mysql就更加没什么实践案例和经验了,大家就不太愿意尝试或者迁移了。 工作中的DDL 大厂来说大体上都是平台封装了,类似idb ,会把无锁变更细节屏蔽了,只需要提工单就可以了...
不靠谱。 我们之前有个项目， 非要用Online DDL去改一个大表的字符集，后来啊直接把主库的IO跑满了主从延迟到了几个小时再说说只能回滚，简直是灾难现场。从那以后凡是涉及到COPY表的DDL，我都老老实实推荐PT-OSC或者gh-ost。
但是PT-OSC也不是省油的灯。有一次主要原因是表上有个外键，PT-OSC默认处理不好，导致数据不一致。后来查了半天文档， 才发现要用这个参数：，是吧？
切记... 关键参数：--alter-foreign-keys-method处理外键依赖，优先选择rebuild_constraints重建约束。
pt-online-schema-change --alter "DROP FOREIGN KEY _fk_order_user" \ --alter-foreign-keys-method=rebuild_constraints \ --user=admin --password=*** --execute D=testdb,t=order
你看，多坑！不仔细看文档，根本不知道还有这么个坑。
工具大乱炖：到底该选谁？
为了让大家更直观地了解，我特意整理了一个表格：
| 特性/工具 | MySQL Online DDL | PT-OSC | gh-ost | DMS无锁变更 |
|---|---|---|---|---|
| 原理 | 原地修改或Copy表 | 影子表+触发器 | 影子表+无触发器 | 平台封装 |
| 资源消耗 | 中等 | 高 | 中等 | 可控 |
| 支持DDL范围 | 受限 | 几乎全部 | 几乎全部 | 广 |
| 外键支持 | 支持 | 支持 | 不支持 | 支持 |
| 触发器依赖 | 无 | 有 | 无 | 无 |
| 适用版本 | 5.6+ | 5.0+ | 5.0+ | 云数据库 |
可以覆盖大范围的DDL类型,但仍然有些常见的DDL类型无法覆盖。 支持的数据库类型 RDS MySQL、 PolarDB MySQL版、MyBase MySQL、其他来源MySQL。 功能特点 相比较数据库原生,DMS无锁结构变更支持控制变更的施行速率,可避免数据库主备链路延迟,对数据库性能影响更小,并支持多种原生OnlineDDL施行时会锁表的场景。 总的来说... 相比较PT-Online、OSC等其它工具,DMS无锁结构变更不依赖于触发器,且异步施行时对数据库的影响非常小,可随时平安中断。 DMS无锁结构...
看到没？DMS这种云厂商的工具，其实就是把PT-OSC或者gh-ost封装了一层，收你钱， 我倾向于... 顺便帮你把坑填了。如果你有钱，用DMS肯定是最省心的。如果你没钱，那就自己折腾吧。
没有银弹，只有取舍
回到开始提出的那个问题,这个问题要看场景,当并发量不大时,可以采用中间表-rename的方案,即使存在短暂不可用,其实影响非常小,而且应该很多人也这样干过。但如果是高并发场景下,策略就略有不同,如下:先说说,DDL变更应该尽可能选择业务相对空闲时,以免影响服务。 接下来,如果是MySQL 5.6以前的版本,推荐使用pt-osc工具实时DDL变更,原理是:通过创建表的拷贝来进行,期间支持DML变更。如果是MySQL 5.5以及以上,由于MySQL原生支持Online DDL特性,所以呢推荐使用原生Onlie DDL,但是如果DDL变更需要进行COPY TABLE操作,则还是推荐使用online-s...，尊嘟假嘟？
Copy方式简单过程：先说说按照原表定义创建一个新的临时表， 然后对原表加写锁，接着在步骤1创建的临时表施行 DDL，然后将原表中的数据copy到临时表，再说说释放原表的写锁将原表删除，并将临时表重命名为原表
说到底，Online DDL和PT-OSC没有绝对的胜负。
- 如果你只是加个索引， 改个默认值，Online DDL绝对是首选，简单、快速、原生支持。
- 如果你要改列类型、 改字符集，或者表特别大，业务并发特别高，PT-OSC虽然麻烦，但是更稳妥，至少不会让你猝死。
- 如果你追求极致， 不想用触发器，那可以去看看gh-ost虽然配置更复杂，但是它真的没有触发器！
对于DDL操作的灵活度掌控,可暂停,可动态修改参数;DBA可以,可快可慢,实现DDL操作性能和对业务影响的平衡; 更为稳健的切表控制:将-cut-over-lock-timeout-seconds和-default-retries配合使用,可以对切表进行灵活的控制。避免pt-osc切表异常导致对业务造成严重影响; 官方Online-DDL为什么不火? 主要原因是出的太晚了 ,然后percona和 gh-ost等等开源产品已经大规模实践了,Mysql就更加没什么实践案例和经验了,大家就不太愿意尝试或者迁移了。 工作中的DDL 大厂来说大体上都是平台封装了,类似idb ,会把无锁变更细节屏蔽了,只需要提工单就可以了...
再说说 我想说的是无论你选哪个，测试！千万不要直接在生产环境上跑！先在测试环境跑一遍，看看资源消耗，看看锁表时间。别等到凌晨三点被报警 求锤得锤。 文章浏览阅读730次。online ddl是mysql 5.6版本新增的功能,之前版本做ddl,为了避免堵塞DML一般都是选择pt-osc工具,或者是采用主从滚动操作的方式。采用滚动的方式,操作复杂,采用pt-osc工具则有一些限制,比如表需要主键或者唯一键,否则不予施行,而且触发器在一定情况下会导致死锁,对... alter table online_test modify c3 varchar default 'test'; 不堵塞读写， 一边整个过程非常迅速，基本不消耗时间 5.添加secondary key alter table online_test add key 不堵塞读写，一边表不会rebuild，也就是磁盘空间并不需要增加一倍，但是还是会产生一个临时的frm文件。 如果指定algorithm=cop... 物超所值。 pt-online-schema-change:pt-online-schema-change是Percona Toolkit中的一个工具,它可以在不停止MySQL服务器的情况下对表结构进行修改。pt-online-schema-change使用了InnoDB存储引擎的特性来实现无锁变更。与OSC不同的是,pt-online-schema-change使用了一个代理表来实现表结构变更,而不是直接在原表上进行修改。 gh-ost:gh-ost是GitHub开源的一个工具,它可以在不停止MySQL服务器的情况下对表结构进行修改。gh-ost使用了InnoDB存储引擎的特性来实现无锁变更。与pt-online-schema-change不同的是,gh-ost使用了一个ghost表来实现表结构变更,而不是使用代理表。 好了废话不多说了希望大家在DDL的道路上少走弯路，少踩坑。毕竟头发是很珍贵的，掉一根就少一根啊！大家下次见，我深信...！
高并发下MySQL无锁变更，Online DDL和PT-OSC哪个更胜一筹？
哎呀，说到这个高并发下的MySQL变更，真的是一把辛酸泪啊！谁没在大半夜被叫起来修过数据库呢？那种感觉，简直了。今天咱们就来好好唠唠这个让人头秃的问题：到底是用原生的Online DDL，还是用老牌的PT-OSC？这不仅仅是个技术选型，简直就是一场赌博！赌赢了相安无事；赌输了那就是全站崩溃，老板拿着刀站在你身后，公正地讲...。
先说说 我们得明白一个事儿，无锁变更这四个字听起来很美，其实吧坑多着呢。很多人以为开了Online DDL就真的“Online”了业务完全不受影响，天真！太天真了，简直了。！
MySQL 5.6+的Online DDL：真的那么香吗？
MySQL 5.6开始支持Online DDL操作。在这之前,对表的修改会阻塞整个表的读写操作。 在5.6之后,可以使用ALTER TABLE语句的ALGORITHM和LOCK子句来控制DDL操作的各个方面。这些子句位于语句的末尾,通过逗号与表和列规范分开。比方说: ALTER TABLE tbl_name ADD PRIMARY KEY , ALGORITHM=INPLACE, LOCK=NONE; LOCK子句有助于微调对表的并发访问程度。
ALGORITHM子句主要用于性能比较,以及作为在遇到任何问题时回落到旧的表复制行为的备用方案。
听起来是不是很完美？ALGORITHM=INPLACE和LOCK=NONE参数实现“原地修改”，避免全表拷贝。但是兄弟们，别高兴得太早！这玩意儿限制一大堆，我懂了。！
比如你想加个索引， 那没问题，速度飞快：
ALTER TABLE user_order ADD INDEX idx_user_id , ALGORITHM=INPLACE, LOCK=NONE;
纯正。 但是一旦你要改列的类型，或者改字符集，嘿嘿，它立马就变脸了！它可能还是会去COPY表， 虽然它号称是Online的，但其实吧那个资源消耗，简直能把你的磁盘IO跑满。这时候，所谓的“无锁”就变成了“无限制”地占用资源！
到位。 文章浏览阅读4.3k次。_online ddl 什么是Online DDL ? 最新推荐文章于 2025-04-10 17:51:41 发布 原创于 2020-04-05 20:10:44 发布·4.3k 阅读·1 · ·CC 4.0 BY-SA版权版权声明:本文为博主原创文章,遵循 CC 4.0 BY-SA版权协议,转载请附上原文出处链接和本声明。 文章标签: #mysqlChenzxxxx关注点赞 踩 收藏 觉得还不错?一键收藏 评论 分享复制链接分享到 QQ分享到新浪微博扫一扫 举报举报online-DDL详细原理介绍及gh-ost讲解 jiaona_chen123的博客06-221万+ 1.MySQL onlineDDL各版本介绍 1.1onlineDDLinmysql5.5 在mysql5.5版本中已经增加了in-place方式,但依然会阻塞...
说白了就是... 你看，连官方文档都还是会锁表的，虽然时间很短，但在高并发下那一瞬间的锁表，就可能导致大量的线程堆积，像雪崩一样！
PT-OSC：老当益壮还是累赘？
再来说说PT-OSC。这可是个老古董了Percona Toolkit里的神器。PT-OSC通过影子表+触发器实现无锁变更。这原理听着就挺复杂的，对吧？
pt-osc 主要用于修改表时不锁表， 简单地说先说说创建一个与原始表一样的新的空表，并根据需要更改表结构，主要原因是是空表修改表结构速度会非常快，然后将原始表中的数据以小块形式复制到新表中， 我的看法是... 接着删除原始表，再说说将新表重命名为原始名称。在复制过程中， 对原始表的所有新的更改都将应用于新表，主要原因是在原始表上创建了一个触发器，以确保所有新的更改都将应用于新表。
坦白说... 这玩意儿的好处是稳！不管你什么DDL，它都能搞定，主要原因是它本质上是新建了一张表。但是坏处也显而易见：触发器！
如果你的业务写入量非常大，那个触发器简直就是性能杀手！每一条写入都要被触发器拦截，再同步到新表。 别担心... CPU直接爆炸，主从延迟也会让你怀疑人生。而且，它还要求表必须有主键，没主键？对不起，不伺候！
pt-online-schema-change --alter "MODIFY c VARCHAR NOT NULL DEFAULT ''" \ --user=admin --password=*** --host=127.0.0.1 --port=3306 \ --execute D=testdb,t=user_info --no-check-alter
你看这命令，参数多到让人眼花缭乱。一旦参数配错了 比如那个--chunk-size设得太大了磁盘IO瞬间被打满； 挽救一下。 设得太小了跑个DDL要跑到下个世纪去。这哪里是工具，简直是折磨！
场景大乱斗：谁才是真正的王者？
咱们来点实际的，看看具体场景下这两个货到底谁更胜一筹。
场景1：添加二级索引
奥利给！ 这种情况下Online DDL简直是吊打PT-OSC。为什么？主要原因是Online DDL添加索引是In-Place的，不需要全表拷贝，速度极快，而且几乎不锁表。你用PT-OSC的话，还得建个影子表，还得搞触发器，纯属脱裤子放屁——多此一举。
优势：无需重建表，仅修改元数据，允许并发DML操作。 代码语言：javascript，别担心...
但是 如果你是MySQL 5.6以前的版本，那不好意思，Online DDL要么不支持， 对，就这个意思。 要么支持得不好，这时候老老实实用PT-OSC吧，虽然慢点，但至少能跑。
场景2： VARCHAR列长度
这个就有点意思了。Online DDL支持，但是有条件！限制：VARCHAR列所需的长度字节数必须保持不变。0~255需要一个字节来编码值,大于等256需要两个字节来编码。使用In Place ALTER TABLE只支持将VARCHAR列大小从0到255字节增加，或从256字节增加到更大的大小。反之需要使用ALGORITHM=COPY才可以。
ALTER TABLE product MODIFY description VARCHAR, ALGORITHM=INPLACE, LOCK=NONE;
如果你不小心跨越了那个字节边界， Online DDL立马退化成COPY模式，那跟锁表也没什么两样了甚至更惨，主要原因是资源占用更高。 来日方长。 这时候， PT-OSC虽然笨重，但至少可控，你可以通过--max-load参数控制负载，别把数据库搞挂了。
场景3：修改列类型
这种情况下 Online DDL大体上是废了必须COPY表。这时候PT-OSC就成了救命稻草。虽然它也COPY表，但它是在后台偷偷地COPY， 栓Q！ 业务还能继续跑。而Online DDL一旦开始COPY，那个锁表的时间，可能会让你直接失业。
说明：需确保原表有主键，且新列允许NULL或指定默认值。 我无法认同... 场景：需一边添加索引并修改列类型。
那些年我们踩过的坑
说实话，这俩工具，谁也没比谁高贵多少。Online DDL虽然官方， 但是出的太晚了然后percona和 gh-ost等等开源产品已经大规模实践了,Mysql就更加没什么实践案例和经验了,大家就不太愿意尝试或者迁移了。 工作中的DDL 大厂来说大体上都是平台封装了,类似idb ,会把无锁变更细节屏蔽了,只需要提工单就可以了...
不靠谱。 我们之前有个项目， 非要用Online DDL去改一个大表的字符集，后来啊直接把主库的IO跑满了主从延迟到了几个小时再说说只能回滚，简直是灾难现场。从那以后凡是涉及到COPY表的DDL，我都老老实实推荐PT-OSC或者gh-ost。
但是PT-OSC也不是省油的灯。有一次主要原因是表上有个外键，PT-OSC默认处理不好，导致数据不一致。后来查了半天文档， 才发现要用这个参数：，是吧？
切记... 关键参数：--alter-foreign-keys-method处理外键依赖，优先选择rebuild_constraints重建约束。
pt-online-schema-change --alter "DROP FOREIGN KEY _fk_order_user" \ --alter-foreign-keys-method=rebuild_constraints \ --user=admin --password=*** --execute D=testdb,t=order
你看，多坑！不仔细看文档，根本不知道还有这么个坑。
工具大乱炖：到底该选谁？
为了让大家更直观地了解，我特意整理了一个表格：
| 特性/工具 | MySQL Online DDL | PT-OSC | gh-ost | DMS无锁变更 |
|---|---|---|---|---|
| 原理 | 原地修改或Copy表 | 影子表+触发器 | 影子表+无触发器 | 平台封装 |
| 资源消耗 | 中等 | 高 | 中等 | 可控 |
| 支持DDL范围 | 受限 | 几乎全部 | 几乎全部 | 广 |
| 外键支持 | 支持 | 支持 | 不支持 | 支持 |
| 触发器依赖 | 无 | 有 | 无 | 无 |
| 适用版本 | 5.6+ | 5.0+ | 5.0+ | 云数据库 |
可以覆盖大范围的DDL类型,但仍然有些常见的DDL类型无法覆盖。 支持的数据库类型 RDS MySQL、 PolarDB MySQL版、MyBase MySQL、其他来源MySQL。 功能特点 相比较数据库原生,DMS无锁结构变更支持控制变更的施行速率,可避免数据库主备链路延迟,对数据库性能影响更小,并支持多种原生OnlineDDL施行时会锁表的场景。 总的来说... 相比较PT-Online、OSC等其它工具,DMS无锁结构变更不依赖于触发器,且异步施行时对数据库的影响非常小,可随时平安中断。 DMS无锁结构...
看到没？DMS这种云厂商的工具，其实就是把PT-OSC或者gh-ost封装了一层，收你钱， 我倾向于... 顺便帮你把坑填了。如果你有钱，用DMS肯定是最省心的。如果你没钱，那就自己折腾吧。
没有银弹，只有取舍
回到开始提出的那个问题,这个问题要看场景,当并发量不大时,可以采用中间表-rename的方案,即使存在短暂不可用,其实影响非常小,而且应该很多人也这样干过。但如果是高并发场景下,策略就略有不同,如下:先说说,DDL变更应该尽可能选择业务相对空闲时,以免影响服务。 接下来,如果是MySQL 5.6以前的版本,推荐使用pt-osc工具实时DDL变更,原理是:通过创建表的拷贝来进行,期间支持DML变更。如果是MySQL 5.5以及以上,由于MySQL原生支持Online DDL特性,所以呢推荐使用原生Onlie DDL,但是如果DDL变更需要进行COPY TABLE操作,则还是推荐使用online-s...，尊嘟假嘟？
Copy方式简单过程：先说说按照原表定义创建一个新的临时表， 然后对原表加写锁，接着在步骤1创建的临时表施行 DDL，然后将原表中的数据copy到临时表，再说说释放原表的写锁将原表删除，并将临时表重命名为原表
说到底，Online DDL和PT-OSC没有绝对的胜负。
- 如果你只是加个索引， 改个默认值，Online DDL绝对是首选，简单、快速、原生支持。
- 如果你要改列类型、 改字符集，或者表特别大，业务并发特别高，PT-OSC虽然麻烦，但是更稳妥，至少不会让你猝死。
- 如果你追求极致， 不想用触发器，那可以去看看gh-ost虽然配置更复杂，但是它真的没有触发器！
对于DDL操作的灵活度掌控,可暂停,可动态修改参数;DBA可以,可快可慢,实现DDL操作性能和对业务影响的平衡; 更为稳健的切表控制:将-cut-over-lock-timeout-seconds和-default-retries配合使用,可以对切表进行灵活的控制。避免pt-osc切表异常导致对业务造成严重影响; 官方Online-DDL为什么不火? 主要原因是出的太晚了 ,然后percona和 gh-ost等等开源产品已经大规模实践了,Mysql就更加没什么实践案例和经验了,大家就不太愿意尝试或者迁移了。 工作中的DDL 大厂来说大体上都是平台封装了,类似idb ,会把无锁变更细节屏蔽了,只需要提工单就可以了...
再说说 我想说的是无论你选哪个，测试！千万不要直接在生产环境上跑！先在测试环境跑一遍，看看资源消耗，看看锁表时间。别等到凌晨三点被报警 求锤得锤。 文章浏览阅读730次。online ddl是mysql 5.6版本新增的功能,之前版本做ddl,为了避免堵塞DML一般都是选择pt-osc工具,或者是采用主从滚动操作的方式。采用滚动的方式,操作复杂,采用pt-osc工具则有一些限制,比如表需要主键或者唯一键,否则不予施行,而且触发器在一定情况下会导致死锁,对... alter table online_test modify c3 varchar default 'test'; 不堵塞读写， 一边整个过程非常迅速，基本不消耗时间 5.添加secondary key alter table online_test add key 不堵塞读写，一边表不会rebuild，也就是磁盘空间并不需要增加一倍，但是还是会产生一个临时的frm文件。 如果指定algorithm=cop... 物超所值。 pt-online-schema-change:pt-online-schema-change是Percona Toolkit中的一个工具,它可以在不停止MySQL服务器的情况下对表结构进行修改。pt-online-schema-change使用了InnoDB存储引擎的特性来实现无锁变更。与OSC不同的是,pt-online-schema-change使用了一个代理表来实现表结构变更,而不是直接在原表上进行修改。 gh-ost:gh-ost是GitHub开源的一个工具,它可以在不停止MySQL服务器的情况下对表结构进行修改。gh-ost使用了InnoDB存储引擎的特性来实现无锁变更。与pt-online-schema-change不同的是,gh-ost使用了一个ghost表来实现表结构变更,而不是使用代理表。 好了废话不多说了希望大家在DDL的道路上少走弯路，少踩坑。毕竟头发是很珍贵的，掉一根就少一根啊！大家下次见，我深信...！