关于UTFMB4字符集大表中VARCHAR(32)转VARCHAR(64)的DDL算法、服务影响及最优方案咨询

嘿，我来帮你理清这个MySQL DDL变更的问题，结合5.7版本的特性给你详细解答：

在MySQL 5.7中，将utfmb4字符集下的varchar(32)修改为varchar(64)，这个操作会使用Inplace算法（属于InnoDB在线DDL的范畴）。

原因很简单：你只是扩大了列的长度，而且新长度（64）远低于utfmb4字符集下varchar的最大限制（65535字节）。这种场景下，InnoDB不需要拷贝整张表的数据到新表，只需要在原表上修改元数据，如果该列存在索引，也会以inplace的方式重建索引，不会触发全表拷贝的COPY算法。

虽然是Inplace算法，但并非完全无影响，主要体现在这几点：

• 元数据锁（MDL）的短暂阻塞：DDL操作的启动和收尾阶段，会短暂持有排他MDL锁（中间大部分时间是共享锁，允许正常的DML操作）。如果业务有持续的高频DML请求，可能会出现短暂的锁等待，导致部分请求超时或延迟升高。
• 资源占用：如果表很大且该列有索引，inplace重建索引的过程会占用CPU、IO和内存资源，可能导致数据库负载上升，业务查询或写入的响应时间变长。
• DML兼容性：DDL执行期间，新的写入操作会遵循新的varchar(64)规则，不过InnoDB会保证事务一致性，不会出现数据错乱的问题。

如果担心影响在线业务，优先推荐以下几种方案：

• 使用在线DDL工具（首推）：比如Percona的pt-online-schema-change或者GitHub的gh-ost。这类工具的原理是创建一个结构修改后的新表，然后逐步将原表的数据同步到新表，同步过程中原表可以正常读写，最后只需要极短的时间交换表名即可完成变更。全程几乎不会阻塞业务，还能自定义同步的chunk大小、限速等参数，避免占用过多资源。
• 选择业务低峰期执行：如果不想用第三方工具，可以在凌晨等业务流量最小的时间段执行DDL。此时即使有短暂的资源占用或锁等待，影响的用户数量也最少。同时可以提前监控数据库负载，确保执行过程中资源在可控范围内。
• 调整MySQL参数优化在线DDL：比如增大innodb_online_alter_log_max_size参数，这个参数控制在线DDL过程中记录DML操作的日志大小，避免因为日志写满导致DDL失败；另外可以设置innodb_parallel_read_threads来提升数据读取的并行度，加快DDL执行速度。
• 先在测试环境验证：在和生产环境配置、数据量一致的测试环境先执行一遍DDL，记录执行时间、CPU/IO占用情况，评估对业务的影响后，再在生产环境落地。

内容的提问来源于stack exchange，提问作者Vu Tran