MySQL部分從庫上面由於大量的臨時表tmp_table形成慢查詢

背景描述

# Time: 2019-01-24T00:08:14.705724+08:00
# User@Host: **[**] @  [**]  Id: **
# Schema: sentrymeta  Last_errno: 0  Killed: 0
# Query_time: 0.315758  Lock_time: 0.001693  Rows_sent: 9664  Rows_examined: 36413  Rows_affected: 0
# Bytes_sent: 1616970  Tmp_tables: 1  Tmp_disk_tables: 1  Tmp_table_sizes: 16384
# QC_Hit: No  Full_scan: No  Full_join: No  Tmp_table: Yes  Tmp_table_on_disk: Yes
# Filesort: No  Filesort_on_disk: No  Merge_passes: 0
#   InnoDB_IO_r_ops: 0  InnoDB_IO_r_bytes: 0  InnoDB_IO_r_wait: 0.000000
#   InnoDB_rec_lock_wait: 0.000000  InnoDB_queue_wait: 0.000000
#   InnoDB_pages_distinct: 1085

             total       used       free     shared    buffers     cached
Mem:           125         38         87          0          0         19
-/+ buffers/cache:         18        107
Swap:           31          0         31

root@(none)04:33:02>select version();
+---------------+
| version()     |
+---------------+
| 5.7.19-17-log |
+---------------+
1 row in set (0.00 sec)

root@(none)04:33:07>show variables like '%table_size%';
+---------------------+-----------+
| Variable_name       | Value     |
+---------------------+-----------+
| max_heap_table_size | 134217728 |
| tmp_table_size      | 16777216  |
+---------------------+-----------+
2 rows in set (0.00 sec)

問題分析

Q1：爲何會產生臨時表？

這個很少說，SQL寫的惹不起，反正就是半個小時看不懂的那種，就是一眼就知道必定會產生臨時表的😂~~~

Q2：登陸到機器上去查看內存使用偏小？

由於這個物理機的內存是125G，可是mysql的總數據量不超過1G，全部實際並不須要多少內存就能夠將全部數據都加載都內存中。

Q3：既然內存夠用，爲啥還要在磁盤上產生臨時表？

後面能夠看見數據庫配置的臨時表空間是16M，從慢查詢日誌上來看每個臨時表的大小是16K，在QPS達到必定量了以後，臨時表空間就達到了上限，就會產生臨時磁盤表，看圖下面的產生的【臨時磁盤表/臨時表】的比例也是符合預期，如今大概就每3條SQL其中有一條會產生臨時表。解決辦法就是把tmp_table_size這個參數調大，按照當前的計算，調大一半8M能夠解決問題。可是，我如今的機器配置很豪，就開心的調大10倍啦~~~~

Q4：磁盤上產生臨時表真的是SQL慢的根本緣由嗎？

一般咱們會認爲產生了臨時表，就更不用說臨時磁盤表，大部分就能肯定慢查詢的緣由了。可是此次我仍是懷疑了一下，實在是機器性能太好，想着16K的臨時表真的有這麼大的影響嗎，並且個人磁盤性能【SSD、PCIE】感受也很棒，O(∩_∩)O哈哈~。因此我統計了一下各個階段的執行時間，發現 converting HEAP to ondisk 從內存中拷貝數據到磁盤消耗的時間並很少，16K對於這種高配的機器仍是小case，真正的時間消耗在sending data上，爲啥會這樣呢？看上面的慢查詢日誌發現 Bytes_sent: 1616970 這個是1.54M,消耗時間比較多的是從引擎層發送數據給server層，由於這個SQL最後訪問的數據比較多。作個簡單測試，右邊是原來的SQL執行時間，左邊是我limit 5的統計結果，能夠很直觀的看到sending data時間上的差別，時間上查了0.011001/0.000131 ~ 84倍。可是這個和數據行數並非線性增加關係的，緣由嘛就是磁盤的訪問方式。

show profile for query 8; +----------------------+----------+ | Status | Duration | +----------------------+----------+ | starting | 0.000082 | | checking permissions | 0.000003 | | checking permissions | 0.000001 | | checking permissions | 0.000003 | | Opening tables | 0.000015 | | init | 0.000024 | | System lock | 0.000010 | | optimizing | 0.000010 | | statistics | 0.000098 | | preparing | 0.000014 | | Creating tmp table | 0.000033 | | executing | 0.000002 | | Sending data | 0.000131 | | end | 0.000003 | | query end | 0.000005 | | removing tmp table | 0.000049 | | query end | 0.000002 | | closing tables | 0.000015 | | freeing items | 0.000030 | | cleaning up | 0.000017 | +----------------------+----------+ 20 rows in set, 1 warning (0.00 sec)

show profile for query 1; +---------------------------+----------+ | Status | Duration | +---------------------------+----------+ | starting | 0.000165 | | checking permissions | 0.000005 | | checking permissions | 0.000002 | | checking permissions | 0.000006 | | Opening tables | 0.000027 | | init | 0.000057 | | System lock | 0.000015 | | optimizing | 0.000025 | | statistics | 0.000235 | | preparing | 0.000031 | | Creating tmp table | 0.000066 | | executing | 0.000003 | | Sending data | 0.011001 | | converting HEAP to ondisk | 0.005307 | | Sending data | 0.059461 | | end | 0.000004 | | query end | 0.000011 | | removing tmp table | 0.000137 | | query end | 0.000004 | | closing tables | 0.000026 | | freeing items | 0.000026 | | cleaning up | 0.000022 | +---------------------------+----------+ 22 rows in set, 1 warning (0.00 sec)