在第4天介紹了SQL Query 執行的細節,
今天將更進一步的改進.
第4天介紹的SQL Query 執行的細節,是使用MySQL提供的
SHOW PROFILE 指令,但是可以發覺到有些動作是重複出現的,
若是能夠聚合計算,就能夠知道每種動作執行的總時間.

要如何聚合計算呢?
MySQL 有提供 ANSI SQL-92 標準的 information_schema,
這個在其他RDBMS也有提供,而且一般的user就能夠SELECT到他自己的.
接著將以第5天產生的測試資料表,含有100萬筆資料為例.
這樣MySQL負荷會稍重一些,可以顯示出CPU用量.

asami@[akina]>set profiling=1;

SELECT * FROM ithelp1005;

有100萬筆,咱就不列了,不然可以列到鐵人賽結束,
我大概可以領到"灌水王"特別獎.

SELECT STATE
       , SUM(DURATION) AS TotDur
       , COUNT(1) AS Calls
       , SUM(CPU_USER) AS CPU_USER
       , SUM(CPU_SYSTEM) AS CPU_SYSTEM
  FROM INFORMATION_SCHEMA.PROFILING
 WHERE QUERY_ID = 1
 GROUP BY STATE
 ORDER BY TotDur DESC;

+------------------------------+----------+-------+----------+------------+
| STATE                        | TotDur   | Calls | CPU_USER | CPU_SYSTEM |
+------------------------------+----------+-------+----------+------------+
| Sending data                 | 0.441762 |    47 | 0.421936 |   0.017997 |
| Waiting for query cache lock | 0.000057 |    47 | 0.000000 |   0.000000 |
| freeing items                | 0.000008 |     1 | 0.000000 |   0.000000 |
| end                          | 0.000008 |     1 | 0.000000 |   0.000000 |
| closing tables               | 0.000007 |     1 | 0.000000 |   0.000000 |
| query end                    | 0.000004 |     1 | 0.000000 |   0.000000 |
| cleaning up                  | 0.000002 |     1 | 0.000000 |   0.000000 |
| logging slow query           | 0.000001 |     1 | 0.000000 |   0.000000 |
+------------------------------+----------+-------+----------+------------+
8 rows in set (0.00 sec)

這樣就比MySQL提供的標準指令,可以更適合判讀了.