如何在mysql命令行中查看高精度查詢時間？

我正在通過一些優化工作，並且我注意到在某些mysql轉儲文章和問題（我現在再也找不到我實際上正在查找的文章和帖子）中發佈時，存在高精度執行時間（ 0.05985215秒而不是0.06秒）。如何在mysql命令行中查看高精度查詢時間？

如何在命令行上查看這些更精確的時間？

編輯

的這個例子是：

+----------+ 
| COUNT(*) | 
+----------+ 
| 11596 | 
+----------+ 
1 row in set (0.05894344 sec)

使用分析得到了我的存在方式的一部分，而是產生一個輸出太長了，我一定要記得啓用它。我只是尋找一個簡單的高精度持續時間。

SET profiling = 1; 
<query> 
SHOW PROFILES;

給了我這樣的事情：

+----------------------+-----------+ 
| Status    | Duration | 
+----------------------+-----------+ 
| (initialization)  | 0.000005 | 
| checking permissions | 0.00001 | 
| Opening tables  | 0.000499 | 
| Table lock   | 0.000071 | 
| preparing   | 0.000018 | 
| Creating tmp table | 0.00002 | 
| executing   | 0.000006 | 
| Copying to tmp table | 6.565327 | 
| Sorting result  | 0.000431 | 
| Sending data   | 0.006204 | 
| query end   | 0.000007 | 
| freeing items  | 0.000028 | 
| closing tables  | 0.000015 | 
| logging slow query | 0.000005 | 
+----------------------+-----------+ 
14 rows in set (0.00 sec)

來源

2011-05-23 Ben Dauphinee

心態後鏈接到包含高精度的執行時間（0.05985215秒而不是0.06秒）_的_articles和問題：您可以通過施加反向補丁恢復到原來的二進制？我似乎無法找到任何。猜想回答你的問題的最快方法就是問這些文章的海報，並詢問他們是如何做到的。 – 2011-05-25 12:48:44

真正的問題是服務器是否支持它。分析將顯示每個步驟所花費的CPU時間，不包括同時運行的**併發查詢**。所以我們必須檢查我們是否有一些** getrusage **沒有分析。 – vbence 2011-05-25 15:15:30

看來最好的答案是啓用分析。沒有其他的線索可以氾濫。

最佳答案，使用查詢分析。

SET profiling = 1; 
<query> 
SHOW PROFILES;

來源

2011-06-02 18:26:53

沒有看到你所談論的垃圾場，它可能是一個用戶定義的函數？看到這個線程（http://lists.mysql.com/internals/33707）的幾個陷阱和如何做到這一點。

來源

2011-05-24 15:59:51 Dycey

但是，這隻會告訴您需要多少時間才能返回。就像你在程序中查詢之前和之後保存microtime一樣。換句話說，如果一個緩慢的查詢運行在另一個線程上，它也會增加查詢的運行時間。 - 一個真正的解決方案必須是基於** getrusage（）**的，僅用於計算線程中運行的CPU時間（運行您的查詢）。 – vbence 2011-05-25 14:36:42

這個問題最好通過查看source of the mysql command line client來解決。的relevant piece of code，

static void nice_time(double sec,char *buff,bool part_second) 
{ 
    // ... 
    if (part_second) 
    sprintf(buff,"%.2f sec",sec); 
    else 
    sprintf(buff,"%d sec",(int) sec); 
}

具有小數點的秒值後的位數硬編碼成（）。這將使我得出結論，更高的精確時間是而不是可能與股票MySQL安裝。

當然，您可以修補此代碼，使其可配置等，並install from source。我想這是你提到的文章和問題中的人在做什麼。找出最好的機會就是問問他們（請參閱我對你問題的評論）。

來源

2011-05-25 14:35:15

@ax顯然我只知道解決這個問題的第一部分。我設法增加了有效位數，但我認爲結果在它被輸入到這裏之前在其他地方被截斷。 – 2011-05-25 17:32:58

@Ben Dauphinee你問過那些使用_高精度時間_他們是怎麼做的？這應該比我更容易爲你打補丁:) – 2011-05-25 21:18:21

@ax我已經在MySQL論壇發佈了一個線程，詢問是否或如何做到這一點。當我得到它們時，我會交叉發佈結果，並接受它在這個方向上的答案。 – 2011-05-25 21:23:48

不優雅，但工作的解決方案是修補/usr/bin/mysql：

# copy the original mysql binary to your home dir 
cp /usr/bin/mysql ~/mysql 
# patch it 
sed -i -e 's/%.2f sec/%.8f sec/1' ~/mysql 
# run it from the home directory 
~/mysql

它的工作原理，因爲目前只有一個格式字符串在mysql二進制「.2f秒％」，但它可能會改變隨着時間的推移。

sed -i -e 's/%.8f sec/%.2f sec/1' ~/mysql

來源

2015-06-17 04:08:05 Nopius

對我來說，這是打印出像「設置2行（0.00000000秒）」的結果。但SHOW PROFILES表示這需要大約一毫秒的時間。所以我懷疑源數據提供這個分辨率不夠高，這實際上有幫助。 – 2016-07-01 01:06:00

如何在mysql命令行中查看高精度查詢時間？

回答

相關問題