作者：楊奇龍
網名“北在南方”，7年DBA老兵，目前任職於杭州有贊科技DBA，主要負責數據庫架構設計和運維平臺開發工作，擅長數據庫性能調優、故障診斷。
一、前言
響應時間（response time 簡稱 RT）是從系統接收請求開始到返回響應之間的時間跨度，是一項極其重要的性能指標。它可以從側面反映系統的整體吞吐量，也是業務請求（比如 sql 請求）的性能好壞的判斷依據。
舉個例子 A 要從杭州坐飛機到北京機場，經歷如下：
從公司到蕭山機場 40min
機場安檢，候機，登機 40min
飛機飛行 耗時 100min
飛機落地，打的到望京 耗時40min
RT= 40 + 40 + 100 + 40 =220min其中真正的'執行'時間就飛機飛行的時間（100min+40+40），其他安檢、候機、堵車的都是等待時間。
RT = 等待時間 + 執行時間
假如到機場的過程中發生堵車，或者空中管制導致候機時間延長，整體的 RT 也會變長，但是飛機飛行時間是相對一定的。從技術的角度來看 SQL 的請求路徑
app <---->（網絡建立連接，data 傳輸）<----> proxy <---->（網絡建立連接，data 傳輸）<----> mysql（執行）
因爲網絡問題丟包，重傳等導致數據傳輸時間增加，進而導致總體的 RT 時間增加 ，還有常見的案例 app 服務器 cpu 飆高導致程序執行的速度變慢，JAVA 程序 GC 等因素也會導致 RT 升高。所以說 SQL 慢，其實 RT 就會高。但是反過來 RT 高，不一定是 SQL 慢的原因。如果是開發同學遇到監控尤其是 trace 系統發現某個接口慢了，並不一定是 SQL 慢。
重點：不要把 trace 系統中的監控 rt 直接當做 db 的執行時間
參考案例 strace 案例
二、如何監控
前面說了 RT 的定義以及它所代表意義。接下來我們看看如何監控數據庫的 RT ，現有的方式主要有兩種。
2.1 tcprstat
tcprstat 是 Percona 基於 libpcap 研發的工具，是通過測量 TCP 的 request 和 response 所需的時間間隔，適用於一問一答式協議類型的處理。通常用來監測 MySQL 響應時間，或者說是請求在服務器端的處理時間，其輸出結果包括了響應時間相關的統計值，用來診斷服務器端性能狀況。
舉個例子：
其輸出結果包括了時間戳，以及響應時間的最大值、均值、方差等信息，輸出信息可以通過 -f 參數進行定製，其中響應時間的單位爲微妙。其中對我們比較重要的是：
count：此間隔內處理完成的請求數量。
avg：此間隔內所有完成的請求，響應的平均時間。95_avg：此間隔內，95% 的請求量的平均響應時間，單位微妙，該值較能體現 MySQL Server 的查詢平均響應時間。
如果我們只需要輸出 count, 平均時間，95_avg,99_avg則可以用如下命令。
tcprstat -p 3312 -t 1 -n 0 -l ip_address -f '%Tt%nt%at%95at%99an'
關於 -f 的參數解釋如下，讀者朋友可以根據需要來調整輸出
如果執行tcprstat遇到如下問題
# tcprstat -p 3312 -t 1 -n 5
pcap: SIOCGIFFLAGS: bonding_masters: No such device可以通過指定本地 ip -l local_ip 來解決。
2.2 MySQL 插件
Percona Server 提供一個叫做響應時間區間的功能，將 sql 耗時在指定區間的請求次數和總共的執行時間記錄到表裏面。其中時間區間跨度由 query_response_time_range_base 控制。
常用的區間範圍爲：(0, 0.000001], (0.000001, 0.000010],(0.000010,0.000100],(0.000100,0.001000],(0.001000, 0.010000], (0.010000,0.100000],(0.100000,1.000000],(1,10] 。
從 MySQL 5.6 開始以插件形式安裝：
INSTALL PLUGIN QUERY_RESPONSE_TIME_AUDIT SONAME 'query_response_time.so';
INSTALL PLUGIN QUERY_RESPONSE_TIME SONAME 'query_response_time.so';
INSTALL PLUGIN QUERY_RESPONSE_TIME_READ SONAME 'query_response_time.so';
INSTALL PLUGIN QUERY_RESPONSE_TIME_WRITE SONAME 'query_response_time.so';然後通過 show plugins 命令檢查插件是否安裝成功。
> SHOW PLUGINS;
......
| QUERY_RESPONSE_TIME | ACTIVE | INFORMATION SCHEMA | query_response_time.so | GPL |
| QUERY_RESPONSE_TIME_AUDIT | ACTIVE | AUDIT | query_response_time.so | GPL |
| QUERY_RESPONSE_TIME_READ | ACTIVE | INFORMATION SCHEMA | query_response_time.so | GPL |
| QUERY_RESPONSE_TIME_WRITE | ACTIVE | INFORMATION SCHEMA | query_response_time.so | GPL |
+-----------------------------+----------+--------------------+------------------------+---------
安裝完成之後 在 INFORMATION_SCHEMA 生成三張表
QUERY_RESPONSE_TIME_WRITE 記錄所有寫請求的響應時間分佈
QUERY_RESPONSE_TIME_READ 記錄所有讀請求的響應時間分佈
QUERY_RESPONSE_TIME 可以認爲是所有請求的響應時間分佈。查看 QUERY_RESPONSE_TIME 的內容
查詢結果中 717 個 sql 請求耗時在 (0, 0.000001] 之間。47898 個 sql 請求的耗時在 (0.000001, 0.000010]，總耗時 0.29 秒，其他以此類推。需要注意的是 count 和total是累計值，監控的時候需要取後值減前值除以採樣的時間間隔。
如何開啓響應時間統計
在命令行中執行
SET GLOBAL query_response_time_stats = 1 ;
在 my.cnf 中
query_response_time_stats = 1
重置（將數據清零）三張表的統計值
SET GLOBAL query_response_time_flush='ON';
常用的 sql
INFORMATION_SCHEMA [RW][TEST:qa_single_0:3312] 11:50:44
>SELECT c.count, c.time, (SELECT SUM(a.count) FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as a WHERE a.count != 0) as query_count, (SELECT COUNT(*) FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as b WHERE b.count != 0) as not_zero_region_count, (SELECT COUNT(*) FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME) as region_count FROM INFORMATION_SCHEMA.QUERY_RESPONSE_TIME as c WHERE c.count > 0;
+-------+----------------+-------------+-----------------------+--------------+
| count | time | query_count | not_zero_region_count | region_count |
+-------+----------------+-------------+-----------------------+--------------+
| 1 | 0.000001 | 71370 | 7 | 14 |
| 86 | 0.000010 | 71370 | 7 | 14 |
| 47375 | 0.000100 | 71370 | 7 | 14 |
| 23404 | 0.001000 | 71370 | 7 | 14 |
| 423 | 0.010000 | 71370 | 7 | 14 |
| 79 | 0.100000 | 71370 | 7 | 14 |
| 2 | 1.000000 | 71370 | 7 | 14 |
+-------+----------------+-------------+-----------------------+--------------+
7 rows in set (0.00 sec)通過監控腳本獲取響應時間的數據在 grafna 展示的結果如下：
其他更詳細的介紹可以去查閱 Percona 的官方文檔。
三、小結
本文總結介紹 RT 的在技術體系中的含義，以及介紹兩種監控 MySQL 響應時間的方法。如果有其他更好的方式方法，歡迎讀者朋友一起討論。