mysql 的一次查詢優化過程

有這樣一條查詢語句：

select sum(index_count) as count, theday ,appVersion, channel, type
  from tableA 
 where project_id='qjp' and theday>='2019-05-17' and theday<='2019-05-23' 
 group by theday
複製代碼

執行用時21s. 數據量55萬左右，實在太慢了。

首先我須要肯定這21s 都用在什麼地方了,即性能瓶頸在哪裏。須要用到Msql的 Query Profiler 診斷分析工具。使用方法以下：

1. 開啓 profiling 參數

root@localhost : (none) 10:53:11> set profiling=1;
  Query OK, 0 rows affected (0.00 sec)
複製代碼

2. 執行你的查詢 Query

mysql> select sum(index_count) as count, theday from tableA where project_id='qjp' and theday>='2019-05-17' and theday<='2019-05-23' group by theday
+-----------+-----------+------------+------------+------
| count     | theday     | appVersion | channel  | type | 
+-----------+-----------+------------+------------+------
| 180205137 | 2019-05-17 | 1.2.6      | 55550006 |      | 
| 168597045 | 2019-05-18 | 1.2.7      | 55550337 |      | 
| 153154098 | 2019-05-19 | 1.2.7      | 55550006 |      | 
+-----------+------------+------------+----------+------+
7 rows in set (21.03 sec)
複製代碼

在開啓 Query Profiler 功能以後，MySQL 就會自動記錄全部執行的 Query 的 profile 信息了。

3. 獲取系統中保存的全部 Query 的 profile 概要信息

mysql> show profiles;
+----------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------+
| Query_ID | Duration    | Query    |
+----------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------+
|        1 | 21.02640425 | select sum(index_count) as count, theday from tableA where project_id='qjp' and theday>='2019-05-17' and theday<='2019-05-23' group by theday|
+----------+-------------+----------------------------------------------------------------------------------------------------------------------------------------------+
1 row in set, 1 warning (0.00 sec)
複製代碼

經過執行 「show profiles 」 命令獲取當前系統中保存的多個 Query 的 profile 的概要信息。

4. 針對單個 Query 獲取詳細的 profile 信息。

mysql> show profile for query 1;
+----------------------+-----------+
| Status               | Duration  |
+----------------------+-----------+
| starting             |  0.000117 |
| checking permissions |  0.000020 |
| Opening tables       |  0.000032 |
| init                 |  0.000039 |
| System lock          |  0.000021 |
| optimizing           |  0.000023 |
| statistics           |  0.000124 |
| preparing            |  0.000032 |
| Creating tmp table   |  0.000042 |
| Sorting result       |  0.000018 |
| executing            |  0.000016 |
| Sending data         | 21.021533 |
| Creating sort index  |  0.003272 |
| end                  |  0.000019 |
| query end            |  0.000022 |
| removing tmp table   |  0.000728 |
| query end            |  0.000019 |
| closing tables       |  0.000023 |
| freeing items        |  0.000064 |
| logging slow query   |  0.000020 |
| Opening tables       |  0.000025 |
| System lock          |  0.000146 |
| cleaning up          |  0.000051 |
+----------------------+-----------+
23 rows in set, 1 warning (0.00 sec)

複製代碼

從上面的可看出時間主要用在 Sending data ,所謂的「Sending data」 並非單純的發送數據，而是包括「收集 + 發送 數據」。後來我又嘗試將查詢的列減小，可是沒有什麼效果。後來無心間檢查下表結構發現其中 有兩列projet_id和 theday的列類型是text，好像知道什麼了（不知道是誰設計的，可是其實沒有必要），改這兩列爲varchar類型，再執行一次查詢，只用了0.5秒。

自此問題解決。總結一下，設計表的時候，列類型必定要考慮好，text類型儘可能少用，設置爲varchar的時候，長度夠用就好，越短性能越好。

=============我是分割線======下面是追加的內容===================

查看錶結構：

mysql> desc tmp_table;
+-------------+--------------+------+-----+---------+-------+
| Field       | Type         | Null | Key | Default | Extra |
+-------------+--------------+------+-----+---------+-------+
| project_id  | text         | YES  | MUL | NULL    |       |
| index_count | varchar(100) | YES  |     | NULL    |       |
| theday      | text         | YES  | MUL | NULL    |       |
| app_version | varchar(32)  | NO   |     | NULL    |       |
| channel     | varchar(32)  | YES  |     | NULL    |       |
+-------------+--------------+------+-----+---------+-------+
8 rows in set (0.00 sec)
複製代碼

修改列類型：

alter table 表名 MODIFY COLUMN 列名 VARCHAR(16)
複製代碼

對了，在處理的過程當中，我還嘗試了加索引，可是發現加索引後，查詢時間不快反而變的更慢。這裏有一篇關於索引的文章 blog.csdn.net/u014470581/…