出於排查問題的需要，打開了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數據慢了三倍以上。