记一次DedeCMS性能问题定位过程

日前，我司将ECS上自建的mysql数据库迁移到了阿里云的RDS for MySQL，而阿里云的RDS for MySQL是不支持MyISAM引擎的。
https://help.aliyun.com/knowledge_detail/52558.html?spm=5176.11065259.1996646101.searchclickresult.1a8171021PENlL

• 自建mysql数据库引擎为InnoDB的情况下，如何使用阿里云的DTS进行数据的平滑迁移？

1. mysqldump只导出表结构，修改建表语句中的指定的引擎
2. 将修改后的表结构导入到RDS
3. 使用DTS的全量迁移 + 增量迁移
4. 修改项目的数据库配置，重启服务。

---

按照上述步骤迁移顺利完成。不过迁移结束后，同事在使用过程中还是遇到了问题。

问题表现

在CMS后台执行某个操作的时候，等待时间很长，显示502 Bad Gateway。

定位过程

对于习惯了rails框架的我来说（没错，其实我是一个ruby程序员），php这种没有访问日志的语言真的是太奇怪。
因为使用的是nginx + php-fpm，在php-fpm添加了慢日志查询。
慢日志开启配置参见此链接

看到了如下的慢日志：

php-fpm慢日志.png
很明显有是有sql慢查询的。

然后因为不熟悉php写入日志的方式，就采取了最笨的办法，将待执行的sql语句写入了指定的文件。

file_put_contents($_SERVER['DOCUMENT_ROOT'].'/debug.log', "这里是sql语句内容", FILE_APPEND);

发现了如下的语句：

OPTIMIZE TABLE `ded_archives`,`ded_arctiny`,`ded_addoninfos`,`ded_addonspec`,`ded_addonarticle`,`ded_addonimages`,`ded_addonsoft`,`ded_addonshop`;

好嘛，原来你才是罪魁祸首。

继续，通过mysql命令行连接RDS，执行上述sql，耗时1分多！！！

image.png

就是你了。
继续google大法，
https://stackoverflow.com/questions/30635603/what-does-table-does-not-support-optimize-doing-recreate-analyze-instead-me

InnoDB doesn't support the OPTIMIZE the way MyISAM does. It does something different. It creates an empty table, and copies all of the rows from the existing table into it, and essentially deletes the old table and renames the new table, and then runs an ANALYZE to gather statistics. That's the closest that InnoDB can get to doing an OPTIMIZE.

那么，实际上使用InnoDB引擎的表OPTIMIZE的方式和使用MyISAM引擎的表是不一样的。

解决方案

暂时，只是将相关的OPTIMIZE语句注释掉。