爲何你使用MySQL查詢很慢？聰明的人都知道這幾個解決技巧

在作開發的朋友特別是和mysql有接觸的朋友會碰到有時mysql查詢很慢，固然我指的是大數據量百萬千萬級了，不是幾十條了，

解決查詢慢的緣由

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

而到了線上庫，除了出現沒有索引的語句，沒有用limit的語句，還多了一個狀況,mysql鏈接數過多的問題。說到這裏，先來看看之前咱們的監控作法 ：

部署zabbix等開源分佈式監控系統，獲取天天的數據庫的io，cpu，鏈接數 部署每週性能統計，包含數據增長量，iostat，vmstat，datasize的狀況 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

方法二:mysqldumpslow命令

/path/mysqldumpslow -s c -t 10 /tmp/slow-log

這會輸出記錄次數最多的10條SQL語句，其中：

-s, 是表示按照何種方式排序，c、t、l、r分別是按照記錄次數、時間、查詢時間、返回的記錄數來排序，ac、at、al、ar，表示相應的倒敘；

-t, 是top n的意思，即爲返回前面多少條的數據；

-g, 後邊能夠寫一個正則匹配模式，大小寫不敏感的；

好比

/path/mysqldumpslow -s r -t 10 /tmp/slow-log

獲得返回記錄集最多的10個查詢。

/path/mysqldumpslow -s t -t 10 -g 「left join」 /tmp/slow-log

獲得按照時間排序的前10條裏面含有左鏈接的查詢語句。 

最後總結一下節點監控的好處：

輕量級的監控，並且是實時的，還能夠根據實際的狀況來定製和修改 設置了過濾程序，能夠對那些必定要跑的語句進行過濾及時發現那些沒有用索引，或者是不合法的查詢，雖然這很耗時去處理那些慢語句，但這樣能夠避免數據庫掛掉，仍是值得在數據庫出現鏈接數過多的時候，程序會自動保存當前數據庫的processlist，DBA進行緣由查找的時候這但是利器 使用mysqlbinlog 來分析的時候，能夠獲得明確的數據庫狀態異常的時間段。

有些人會建義咱們來作mysql配置文件設置

調節tmp_table_size的時候發現另一些參數

Qcache_queries_in_cache在緩存中已註冊的查詢數目

Qcache_inserts被加入到緩存中的查詢數目

Qcache_hits緩存採樣數數目

Qcache_lowmem_prunes由於缺乏內存而被從緩存中刪除的查詢數目

Qcache_not_cached沒有被緩存的查詢數目 (不能被緩存的，或因爲 QUERY_CACHE_TYPE)

Qcache_free_memory查詢緩存的空閒內存總數

Qcache_free_blocks查詢緩存中的空閒內存塊的數目

Qcache_total_blocks查詢緩存中的塊的總數目

Qcache_free_memory能夠緩存一些經常使用的查詢,若是是經常使用的sql會被裝載到內存。那樣會增長數據庫訪問速度。

以上就是關於對MySQL查詢優化之查詢慢緣由和解決技巧的詳細介紹。歡迎你們對MySQL查詢優化之查詢慢緣由和解決技巧內容提出寶貴意見。

最後

特別推薦一個分享C/C++和算法的優質內容，學習交流，技術探討，面試指導，簡歷修改...還有超多源碼素材等學習資料，零基礎的視頻等着你！

還沒關注的小夥伴，能夠長按關注一下：