在使用云数据库MySQL时，可能会遇到应用程序响应速度变慢的问题。通过查看慢查询日志（slow query log），可以了解执行时间过长的SQL语句，从而找到性能瓶颈并进行优化。
一、启用慢查询日志
默认情况下，MySQL服务器不会记录所有查询到慢查询日志中，而是需要手动开启它。可以通过修改配置文件my.cnf中的参数实现。设置long_query_time参数来指定超过多少秒的查询将被记录下来，还可以设置log_output参数选择输出方式为文件或者表，默认是文件形式存储。也可以直接在命令行输入“set global slow_query_log = ‘ON’;”临时开启该功能。
二、获取慢查询日志
如果选择了以文件形式保存，则可以在数据目录下找到名为“hostname-slow.log”的文本文件；若选的是表格，则需从performance_schema.slow_log或mysql.slow_log表中查询。对于大规模生产环境来说，建议采用专业的监控工具如Percona Monitoring and Management (PMM)等来进行收集和展示。
三、解析慢查询日志
原始的日志内容较为复杂，包含了许多冗余信息，因此需要借助工具对其进行解析。例如pt-query-digest是一个非常流行的开源工具，它可以对慢查询日志进行汇总统计，并按照不同的维度（如查询次数、平均耗时等）排序。这样就能快速定位出最需要优化的SQL语句。
四、针对常见问题的优化方法
1. 索引缺失：当发现某个表上的全表扫描操作频繁出现在慢查询日志里时，很可能是因为缺少了合适的索引来加速查询。此时应该根据具体的业务需求以及字段分布情况，创建一个或多个覆盖索引，确保能够满足大部分查询条件。
2. 复杂的JOIN语句：过多的连接操作会导致CPU资源消耗过大，进而影响整体性能。尽量减少不必要的JOIN层次，避免多表关联带来的笛卡尔积效应。在设计模型之初就要考虑到查询效率，尽可能让相关联的数据集中存储在同一张物理表内。
3. 子查询嵌套：尽量不要使用子查询代替JOIN，因为前者通常会带来更高的开销。如果确实需要表达逻辑上的包含关系，可以考虑使用exists/ not exists语法替代in/not in。
4. 批量插入更新：对于批量写入场景，应优先选用LOAD DATA INFILE或者INSERT … ON DUPLICATE KEY UPDATE等方式，而不是逐条提交事务。这样做不仅提高了吞吐量，而且减少了锁定等待的时间。
五、定期清理慢查询日志
随着时间推移，慢查询日志文件会逐渐增大，占用大量磁盘空间，甚至可能引发其他故障。所以要养成良好的习惯，定期备份并删除历史记录。具体做法可以是在crontab定时任务里添加相应的脚本，按照设定的时间间隔自动完成这项工作。
