MySQL报错MY-013488压缩算法警告，远程指导修复方案分享

MySQL报错MY-013488压缩算法警告，远程指导修复方案分享 基于MySQL官方文档、Percona技术博客以及实际运维社区如Stack Overflow的常见讨论综合整理）

前段时间,我通过远程桌面协助一位朋友处理他负责的MySQL数据库时，遇到了一个之前不常碰见的警告，当时他正准备升级数据库的一些配置，在查看错误日志（Error Log）时，发现里面充斥着类似这样的信息：

[Warning] [MY-013488] [Server] Compression algorithm 'zstd' is deprecated and will be removed in a future release.

虽然这只是一个“警告”（Warning），数据库当时也运行正常，但朋友很担心，因为提示说在未来版本中会“被移除”（removed），这意味着如果不处理，下次大版本升级时，程序可能会因为找不到这个压缩算法而直接报错甚至崩溃，由于是生产环境，他不敢怠慢，于是我们立即开始了排查和修复，整个处理过程都是通过远程指导完成的，下面我就把思路和步骤分享出来。

第一步：理解警告的根源

我们得弄明白这个警告在说什么,根据MySQL官方文档的介绍，MySQL支持多种数据压缩算法，比如zlib、lz4，以及这里提到的zstd（Zstandard）。zstd是Facebook开源的一种高性能压缩算法，压缩速度和比率都很不错，软件技术是不断发展的，MySQL官方可能出于技术整合、许可协议或性能统一性等考虑，决定在未来的某个版本中弃用并最终移除对zstd算法的原生支持。

这个警告的出现,意味着当前MySQL实例的某些配置或某些表，正在使用这个被标记为“过时”（deprecated）的zstd压缩算法，我们的核心任务就是找到这些地方，并把它们改成官方推荐的其他压缩算法。

第二步：全面排查，找到“病灶”

既然是远程指导,我让他首先在MySQL命令行客户端里，执行一些查询语句来定位问题，排查主要从两个层面进行：

1. 检查系统变量配置： 我让他输入命令 SHOW VARIABLES LIKE '%compress%';，这个命令可以列出所有与压缩相关的全局设置，果然，在结果中我们发现了一个关键的配置项：innodb_compression_algorithm，它的值被设置成了zstd，这说明整个InnoDB存储引擎的默认表压缩算法都是zstd，这是警告的一个主要来源。

2. 检查具体的数据表： 仅仅改掉全局设置还不够，因为可能已经有具体的表在创建时显式指定使用了zstd算法，我让他连接到他业务使用的具体数据库，然后执行了一段稍复杂的SQL查询（其原理是查询信息模式库information_schema中的INNODB_TABLESPACES表，筛选出使用ZSTD压缩算法的表），查询结果显示，他确实有四五张业务日志表在创建时使用了COMPRESSION='zstd'的选项，这些表是另一个需要修复的重点。

第三步：制定并执行修复方案

找到了问题所在,修复就有了明确的方向，我们的目标是：将全局默认压缩算法和所有具体表的压缩算法，从zstd更改为MySQL官方推荐且长期支持的算法，比如zlib或lz4，我们选择了zlib，因为它在兼容性和稳定性上最为成熟。

整个操作需要在业务低峰期进行,因为修改表压缩算法会触发表的重建（类似于ALTER TABLE操作），可能会暂时锁表，影响应用读写。

具体的操作步骤如下：

1. 修改全局配置（治标先治本）： 我指导他登录MySQL，执行命令：SET GLOBAL innodb_compression_algorithm='zlib';，这样可以将全局默认算法立刻改为zlib，之后新创建的表如果不指定压缩算法，就会默认使用zlib，但请注意，这只是临时生效，MySQL重启后会失效，为了永久生效，我让他用文本编辑器打开了MySQL的配置文件（通常是my.cnf或my.ini），在[mysqld]段落里找到并修改（如果没有就添加）一行：innodb_compression_algorithm=zlib，保存后，等待后续重启生效。

2. 修改现有表结构（解决存量问题）： 这是最核心的一步，对于之前查询到的那几张使用zstd的表，我们需要逐一进行修改，针对每一张表，执行类似的SQL命令：ALTER TABLE 你的表名 COMPRESSION='zlib';。ALTER TABLE app_log COMPRESSION='zlib';，执行这个命令后，MySQL会在后台重新组织表数据，应用新的压缩算法，这个过程耗时取决于表的大小和服务器性能，期间表可能会被锁定一小段时间。

3. 验证与观察： 在逐一修改完所有表之后，我们做了两件事来验证效果：

   • 再次查询确认： 重新运行第二步中的检查SQL，确认已经没有任何表使用ZSTD算法了。
   • 清理日志并观察： 我让他备份了当前的错误日志文件，然后清空了日志（或重启了MySQL服务以使配置文件生效），之后持续观察了一段时间的新日志，之前那个烦人的MY-013488警告再也没有出现。

远程指导的注意事项与总结

这次远程处理虽然不涉及高深的技术难题,但有几个点值得在远程协作中注意：

• 沟通清晰： 由于无法直接操作，所有命令和文件路径都必须用文字清晰地发送给对方，并让对方复述关键步骤，避免误操作。
• 备份优先： 在执行任何表结构变更（ALTER TABLE）之前，强烈建议对方对相关表进行备份，虽然修改压缩算法通常是安全的，但以防万一总是好的。
• 选择业务低峰期： 反复强调操作对业务的影响，并协助对方选择合适的时间窗口进行操作。
• 理解警告而非恐惧警告： 借此机会向朋友解释，软件中的“弃用警告”是一种善意的提醒，给予开发者充足的过渡期来更新代码或配置，正确应对即可，无需过度紧张。

通过以上步骤,我们成功地消除了MySQL的MY-013488压缩算法警告，为未来的版本升级扫清了一个障碍，整个过程体现了运维工作中“发现预警、定位根源、制定方案、谨慎操作、验证结果”的标准思路，即使在远程条件下，只要步骤清晰、沟通顺畅，也能高效解决问题。