我有一個5GB的數據庫，所有的表都是MyISAM。從上午01:30到上午8:30（超過100次選擇，150次更新，每秒超過200次高速緩存命中）運行時間很長，以便進行數據分析，而在其他時間，負載適中（10次選擇，每秒5次插入）。MySQL無需重啓就定期調優
問題是，幾天後，在重負載時的數據分析似乎放緩可能是由於查詢緩存梅乾（IOWAIT增加）。當前查詢緩存設置爲1.5G，而總RAM爲4G。它手動重新啓動mysql服務器後再次運行。
有沒有辦法做定期的優化或MySQL服務器上的清理，以保持它的運行效率不重啓
這聽起來我喜歡你的應用程序正忙更新表，你可能有表的爭。您是否已經運行mytop，或者SHOW PROCESSLIST能夠讓您瞭解您的應用程序的哪些部分在做最多的工作？你有沒有啓用--slow-query-log設置？
此外，您的數據庫表引擎可能是一個問題。你在使用MyISAM還是InnoDB？您希望在更新期間注意表鎖，以及可以創建多少備份。
如果您正在發行FLUSH QUERY CACHE，可導致不良，運行命令時近鎖定的MySQL展覽的許多版本。
而且在運行頂部和檢查在/ var /日誌/ cron的那些可能會影響系統負載可以幫助cronjobs。如果您在服務器上運行updatedb或logrotate，可能會影響iowait。
看起來你的查詢緩存大小太大了。雖然查詢緩存通常是一件好事，但如果它太大，它可能會傷害更多，然後它會有所幫助。
此行爲this article討論：
這裏的問題是，客戶有寫流量的中等水平，和當前的查詢緩存實現會使所有的結果集爲給定的表，只要該表是更新。隨着查詢緩存的規模增大，對於給定表必須失效的條目數量也會增加。另外，高速緩存上的粗略鎖定會導致鎖定爭用，從而可能導致性能下降，特別是在多核心硬件上。
我會建議您將查詢緩存的大小降低到16-128MB之間，並查看效果如何。
另一種可能性是查詢正在生成導致內存碎片的非常小的結果集。有關這方面的更多信息是available here，請查找「query_cache_min_res_unit」設置。