MySQL打开了慢查询日志引起数据库性能严重下降的教训

出于排查问题的需要，打开了mysql的慢查询日志记录功能，没想到被坑了一把。 总结：在大量数据insert的场景中，开启慢查询日志可能使mysql性能下降3倍以上，开启慢查询日志需要慎重！

慢查询问题记录

所负责的系统有一个接口应用，为客户提供数据查询服务。当处理大并发请求的时候，tomcat日志经常报警：请求耗时过长。tomcat后面的数据源是redis和mysql，检查redis后没发现问题，进而猜想mysql处理性能不足。
为了验证猜想是否正确，打开了mysql的慢查询sql监控功能，设置慢查询阈值为1秒：

set global slow_query_log='ON'; 
set global long_query_time=1;

开启后运行半天，果然发现了mysql性能不足问题，并进行了相应解决。参考权威书籍《高性能mysql》的意见，慢查询对mysql的性能影响可以忽略不计：

在mysql的当前版本（5.5）中，慢查询日志是开销最低、精度最高的测量查询时间的工具。。。在IO密集型场景做过基准测试，慢查询日志带来的开销可以忽略不计（实际上在CPU密集型场景的影响还稍微大一些）。。。

所以放心的打开慢查询日志、没有去关闭慢查询。
然而第二天就发生了问题。

我们的数据库分内网和外网，内网的明文数据通过加密后、用网闸将数据同步到外网数据库，数据量大约一亿。开启慢查询日志的第二天监控报警：外网数据同步异常、指定时间点数据量过少。。。也就是到在规定时间内，mysql的insert任务没有完成~~~

这种网闸同步任务我们同时部署在多个mysql节点，只有开启慢查询的这个节点没在规定时间完成数据同步（内网数据库做select、外网做insert）。相对于正常数据同步（一亿数据耗时1小时），开启慢查询后数据同步（耗时3.5小时）慢了3倍以上：
正常网闸数据同步：

开启慢查询后数据同步时间：

关闭慢查询日志再次进行数据同步，发现同步耗时恢复到1小时的水平。

总结

对于需要大量IO的mysql操作，开启慢查询日志对mysql性能的影响可能远高于理论值，在我们的亿级数据insert场景中，开启慢查询日志后insert数据慢了三倍以上。