2013年5月6日星期一

如何識別MySQL的慢查詢及相關問題

Original Post: http://anothermysqldba.blogspot.com/2013/05/how-to-identify-mysql-slow-queries-and.html


該博客文章的博客系列的一部分
慢查詢日誌說什麼？ 是否包括你的應用程序的關鍵查詢嗎？

多久了MySQL服務器執行查詢，在這種狀態下？
一直緩慢或直到幾個星期前，這些查詢運行得很好？
如果有的話是什麼改變了呢？

您通過以下幾條準則由施洛米諾奇開始。
他有這個博客帖子上列出了一些有用的查詢。
    • “ 查看，如果一些索引是一個前綴的情況（在這種情況下，它是多餘的）” -的諾奇施洛米。
我也建議了解羅納德的文章中所示的概念和工具

因此，讓我們深入到慢查詢的問題多一點。

這是一個簡單的例子，所以你的結果會有所不同。

首先收集一些數字：

％慢查詢
     只是演示數據，所以你的結果會有所不同。 
show status like 'Slow_queries';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Slow_queries | 7 |
+---------------+-------+

show status like 'Questions';
+---------------+-------+
| Variable_name | Value |
+---------------+-------+
| Questions | 84 |
+---------------+-------+
1 row in set (0.01 sec)

SELECT (7 / 84) * 100 as "% Slow Queries";
+----------------+
| % Slow Queries |
+----------------+
| 8.3333 |
+----------------+ 

slow_query_log
收集的位置，其中全職DBA應該已經知道，但為了以防萬一：
show variables like '%slow_query%';
+---------------------+-------------------------------+
| Variable_name | Value |
+---------------------+-------------------------------+
| slow_query_log | ON |
| slow_query_log_file | /var/lib/mysql/mysql-slow.log |
+---------------------+-------------------------------+
2 rows in set (0.00 sec) 

開始尋找這些查詢和運行說明，看看可能是什麼問題。
如果你願意，你可以查看一些工具來幫助。
“ 不同的道路有時會導致相同的城堡 。”
- 喬治RR馬丁 ， 權力的遊戲

“有人誰讀報和當代作家的最好的書在我看來就像一個極其近視的人，誰藐視眼鏡。 他是完全依賴於他那個時代的偏見和時尚，因為他永遠不會看到或聽到了什麼聲音。“ 
- 愛因斯坦

對於最好的結果，使用這些工具之一以上，並確保您獲得大畫面，並了解所呈現給你。
    一旦你找到了你以後的查詢，你需要評估他們EXPLAIN。 然後，您將擁有所需的信息，以幫助您優化查詢和相關的索引，如果需要的話。
    解釋的更多信息，可以發現如下：

    一些額外的關注，以幫助查詢的性能。

    Query Cache的效率
    只是演示數據，所以你的結果會有所不同。 

    > SELECT @@have_query_cache;
    +--------------------+
    | @@have_query_cache |
    +--------------------+
    | YES |
    +--------------------+

    >show status like '%Qcache_hits%';
    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | Qcache_hits | 32 |
    +---------------+-------+
    1 row in set (0.00 sec)

    > show status like '%Com_select%';
    +---------------+-------+
    | Variable_name | Value |
    +---------------+-------+
    | Com_select | 16 |
    +---------------+-------+
    1 row in set (0.00 sec)

    > SELECT ( 32 / (16 + 32) ) * 100 AS "Query Cache Efficiency";
    +------------------------+
    | Query Cache Efficiency |
    +------------------------+
    | 66.6667 |
    +------------------------+
    1 row in set (0.00 sec) 

    我不想改寫彼得已經寫，所以請參閱他的博客文章 。
    評估您的查詢緩存效率如何。 確定性如何查詢？

    恐怖分子需要一個指數
    只是演示數據，所以你的結果會有所不同。   
    > show status like '%Select_range_check%';
    +--------------------+-------+
    | Variable_name | Value |
    +--------------------+-------+
    | Select_range_check | 0 |
    +--------------------+-------+

    > show status like '%Select_full_join%';
    +------------------+-------+
    | Variable_name | Value |
    +------------------+-------+
    | Select_full_join | 1 |
    +------------------+-------+

    > SELECT (0 + 1) AS "# of Joins that need an index";
    #
    This is used below as the numerator in
    "# of Joins that need an index today"
    +-------------------------------+
    | # of Joins that need an index |
    +-------------------------------+
    | 1 |
    +-------------------------------+

    > show status like 'Uptime';
    +---------------+--------+
    | Variable_name | Value |
    +---------------+--------+
    | Uptime | 335243 |
    +---------------+--------+

    > SELECT (1/ (335243/86400 )) as " # of Joins that need an index today" ;
    +-------------------------------------+
    | # of Joins that need an index today |
    +-------------------------------------+
    | 0.2577 |
    +-------------------------------------+ 

    希望你能評估發現的慢查詢日誌審查Query Cache的效率，以及發現的加入，需要從“ 選擇@ slow_query_log_file指數”;

    但願這已經得到開始在MySQL解決一個非常古老的關注。
    发帖者 时间：
    标签： , , , , ,