mysql服務器查詢慢原因分析與解決方法小結

2024-07-24 12:49:17

字體：大中小

來源：轉載

供稿：網友

會經常發現開發人員查一下沒用索引的語句或者沒有limit n的語句，這些沒語句會對數據庫造成很大的影響，例如一個幾千萬條記錄的大表要全部掃描，或者是不停的做filesort，對數據庫和服務器造成io影響等。這是鏡像庫上面的情況。

而到了線上庫，除了出現沒有索引的語句，沒有用limit的語句，還多了一個情況,mysql連接數過多的問題。說到這里，先來看看以前我們的監控做法
1. 部署zabbix等開源分布式監控系統，獲取每天的數據庫的io，cpu，連接數
2. 部署每周性能統計，包含數據增加量，iostat，vmstat，datasize的情況
3. Mysql slowlog收集，列出top 10

以前以為做了這些監控已經是很完美了，現在部署了mysql節點進程監控之后，才發現很多弊端
第一種做法的弊端: zabbix太龐大，而且不是在mysql內部做的監控，很多數據不是非常準備，現在一般都是用來查閱歷史的數據情況
第二種做法的弊端：因為是每周只跑一次，很多情況沒法發現和報警
第三種做法的弊端: 當節點的slowlog非常多的時候，top10就變得沒意義了，而且很多時候會給出那些是一定要跑的定期任務語句給你。。參考的價值不大
那么我們怎么來解決和查詢這些問題呢

對于排查問題找出性能瓶頸來說，最容易發現并解決的問題就是MYSQL的慢查詢以及沒有得用索引的查詢。
OK，開始找出mysql中執行起來不“爽”的SQL語句吧。
=========================================================
方法一：這個方法我正在用，呵呵，比較喜歡這種即時性的。
復制代碼代碼如下:

Mysql5.0以上的版本可以支持將執行比較慢的SQL語句記錄下來。
mysql> show variables like 'long%'; 注：這個long_query_time是用來定義慢于多少秒的才算“慢查詢”
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
1 row in set (0.00 sec)
mysql> set long_query_time=1; 注：我設置了1, 也就是執行時間超過1秒的都算慢查詢。
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'slow%';
+---------------------+---------------+
| Variable_name | Value |
+---------------------+---------------+
| slow_launch_time | 2 |
| slow_query_log | ON | 注：是否打開日志記錄
| slow_query_log_file | /tmp/slow.log | 注：設置到什么位置
+---------------------+---------------+
3 rows in set (0.00 sec)
mysql> set global slow_query_log='ON' 注：打開日志記錄
一旦slow_query_log變量被設置為ON，mysql會立即開始記錄。
/etc/my.cnf 里面可以設置上面MYSQL全局變量的初始值。
long_query_time=1
slow_query_log_file=/tmp/slow.log

上一篇：MySQL主從同步、讀寫分離配置步驟

下一篇：利用MySQL加密函數保護Web網站敏感數據的方法分享

發表評論

共有條評論