在mysql中測試查詢的性能

Question

我正在嘗試設置一個腳本來測試開發mysql服務器上的查詢性能。 這里有更多細節：

• 我有root權限
• 我是訪問服務器的唯一用戶
• 對InnoDB性能最感興趣
• 我優化的查詢主要是搜索查詢（ SELECT ... LIKE '%xy%' ）

我想要做的是創建可靠的測試環境來測量單個查詢的速度，而不依賴於其他變量。

到目前為止我一直在使用SQL_NO_CACHE ，但有時候這些測試的結果也會顯示緩存行為 - 在第一次運行時需要花費更長的時間，並且在后續運行中花費的時間更少。

如果有人能夠詳細解釋這種行為，我可能會堅持使用SQL_NO_CACHE ; 我相信這可能是由於文件系統緩存和/或用於執行查詢的索引的緩存，正如本文所解釋的那樣。 當緩沖池和密鑰緩沖區失效或者它們如何干擾測試時，我不清楚。

因此，如果沒有重新啟動mysql服務器，您會如何建議設置一個可靠的環境來確定一個查詢是否比另一個更好？

Answer 1

假設您無法優化LIKE操作本身，您應該嘗試優化基本查詢，而不會最小化應檢查的行數。

一些可能對此有用的事情：

EXPLAIN SELECT中的rows列...結果。 然后，

mysql> set profiling=1;
mysql> select sql_no_cache * from mytable;
 ...
mysql> show profile;
+--------------------+----------+
| Status             | Duration |
+--------------------+----------+
| starting           | 0.000063 |
| Opening tables     | 0.000009 |
| System lock        | 0.000002 |
| Table lock         | 0.000005 |
| init               | 0.000012 |
| optimizing         | 0.000002 |
| statistics         | 0.000007 |
| preparing          | 0.000005 |
| executing          | 0.000001 |
| Sending data       | 0.001309 |
| end                | 0.000003 |
| query end          | 0.000001 |
| freeing items      | 0.000016 |
| logging slow query | 0.000001 |
| cleaning up        | 0.000001 |
+--------------------+----------+
15 rows in set (0.00 sec)

然后，

mysql> FLUSH STATUS;
mysql> select sql_no_cache * from mytable;
...
mysql> SHOW SESSION STATUS LIKE 'Select%';
+------------------------+-------+
| Variable_name          | Value |
+------------------------+-------+
| Select_full_join       | 0     |
| Select_full_range_join | 0     |
| Select_range           | 0     |
| Select_range_check     | 0     |
| Select_scan            | 1     |
+------------------------+-------+
5 rows in set (0.00 sec)

另一個有趣的值是last_query_cost ，它顯示了優化程序估計查詢的代價（值是隨機頁面讀取的數量）：

mysql> SHOW STATUS LIKE 'last_query_cost';
+-----------------+-------------+
| Variable_name   | Value       |
+-----------------+-------------+
| Last_query_cost | 2635.399000 |
+-----------------+-------------+
1 row in set (0.00 sec)

MySQL文檔是你的朋友。

Answer 2

從此頁面引用： SQL_NO_CACHE選項影響查詢緩存中查詢結果的緩存 。 如果您的表非常小，那么表本身就已經被緩存了。 由於您只是避免緩存結果而不是表，因此有時會得到所描述的行為。 因此，正如其他帖子中所述，您應該在查詢之間刷新表 。

Answer 3

正如鏈接文章所建議的那樣，在測試運行之間使用FLUSH TABLES盡可能多地重置（特別是查詢緩存）。

您的測試是否應該考慮到InnoDB在實際執行期間本身會有不同的狀態，這樣您就會對多次試驗的總體性能感興趣？ 如果你想為每次試驗重置InnoDB，你的性能測試會有多“真實”嗎？ 您拒絕的查詢，因為它在重新啟動后立即執行不佳可能是InnoDB稍微預熱后的最佳查詢。

如果我是你，我會專注於查詢優化器與InnoDB的性能分開進行的操作。 有很多關於如何調整InnoDB的文章，但它有助於開始有好的查詢。

您還可以嘗試使用等效的MyISAM表來測量性能，其中FLUSH TABLES真的會將您重置為一個大致相同的起點。

您是否嘗試完全關閉查詢緩存？ 即使使用SQL_NO_CACHE，只需要打開查詢緩存就會有3％的懲罰。

Answer 4

你考慮過使用Maatkit嗎？ 我稍微熟悉的一個功能是使用tcpdump捕獲MySQL網絡數據，並使用mk-query-digest處理轉儲。 此工具允許您顯示有關每個查詢的一些細粒度的詳細信息。 但是還有一大堆其他工具可以使查詢分析更容易。

Answer 5

你可以嘗試mysql工作台，我認為它有一個sql語句監視器，所以你可以看到它有多快，為什么它快

Answer 6

InnoDB上的全文查詢很慢（LIKE“％query％”語句），沒有什么可以做的來優化它們。 解決方案不同於將您查詢的特定表傳遞給MyISAM，因此您可以創建全文索引（innoDB不支持），將行反規范化為可搜索的索引（不推薦），Doctrine ORM提供了一個簡單的示例，說明如何實現此目的： http://www.doctrine-project.org/documentation/manual/1_1/nl/behaviors:core-behaviors:searchable你的問題的“正確”解決方案是索引你使用全文搜索的信息，用像Sphinx Search或Apache Solr這樣的解決方案。

如前所述，在比較結果時必須考慮緩存狀態，引導緩存提供極其高效的查詢。 您應該考慮特定查詢的緩存命中百分比，即使它是一個昂貴的查詢，如果它具有99％的緩存命中率，平均性能將非常高。

細粒度的查詢調整不是一個靈丹妙葯，為了優化整個生產環境，您可能會增加應用程序的復雜性，可忽略不計。

考慮您的工作負載，對頻繁，不良的查詢進行故障排除（使用mysql中的slow_query_log，不要盲目地開始優化查詢）。