从Dump恢复后AWS RDS（db.m6i.large）WordPress数据库CPU占满问题排查

你的mysqldump导出命令本身没有问题，--quick、--single-transaction是针对InnoDB数据库导出的标准优化参数，--no-tablespaces也是适配AWS RDS的正确配置。问题并非出在导出环节，而是恢复后的实例状态或配置差异导致的。

核心问题定位 #

wait/io/file/myisam/dfile等待事件说明当前数据库存在大量MyISAM表的磁盘IO操作。MyISAM采用表级锁机制，高并发场景下会引发线程等待锁的循环重试，直接导致CPU占满。原t3.medium实例无此问题，大概率是以下原因：

• 存储引擎不一致：原RDS实例中WordPress的表可能全部使用InnoDB，但恢复后部分或全部表被转为MyISAM。可能是恢复时MySQL客户端默认存储引擎为MyISAM，或者备份文件中部分表本身定义为MyISAM（比如某些老旧WordPress插件生成的表）。
• 参数组配置差异：新m6i.large实例的RDS参数组配置不合理，比如key_buffer_size（MyISAM缓存）设置过小，导致频繁磁盘读；或innodb_buffer_pool_size（InnoDB缓存）不足，即使是InnoDB表也出现性能瓶颈。
• 实例特性差异：t3系列是突发性能实例，平时IO可能被限制，但爬虫负载较低时未触发瓶颈；m6i是通用型实例，IO性能更高，但MyISAM的锁机制反而放大了并发冲突。

具体解决步骤 #

1. 检查并转换存储引擎
   登录新实例的MySQL控制台，执行以下命令查看目标库的表存储引擎：

   SELECT table_name, engine FROM information_schema.tables WHERE table_schema = 'wp-staging';
   

   若发现MyISAM表，将其转换为InnoDB（WordPress官方推荐使用InnoDB）：

   ALTER TABLE wp_comments ENGINE=InnoDB;
   ALTER TABLE wp_posts ENGINE=InnoDB;
   -- 其他MyISAM表依次执行上述命令，或编写批量脚本处理
   

2. 调整RDS参数组

   • 修改default_storage_engine为InnoDB，确保后续新建表默认使用InnoDB。
   • 若必须保留MyISAM表，调大key_buffer_size（建议设置为实例内存的10%-20%，m6i.large有8GB内存，可设为1GB左右）。
   • 针对InnoDB表，调大innodb_buffer_pool_size（建议设置为实例内存的50%-70%，m6i.large可设为4GB-5GB）。

3. 优化爬虫与SQL
   检查爬虫是否在短时间内发起大量并发查询，或存在未加索引的低效SQL。原实例可能因负载低未暴露问题，新实例的高CPU性能反而让MyISAM的锁瓶颈更突出。可通过EXPLAIN分析爬虫执行的SQL，添加必要索引优化查询性能。

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