因MYSQL 現在業務量不大，使用也不多，為了便捷及安全考慮。就不再自己架構數據庫了，直接放到的阿里的RDS 服務中。

但前幾天開發的測試下來，總說RDS還不如自己測試庫壓測快。

查看了RDS下的數據，如下：

數據分布及其不平衡，查詢一個用戶的數據很多，其它卻很少，

MySQL [GTUAN]> select MallID,UserId,count(*) from `order` group by MID,UserId order by count(*) desc;
+--------+---------+----------+
| MID | UserId? | count(*) |
+--------+---------+----------+
|? 10008 | 3705695 |??? 49387 |
|? 10008 | 5033586 |?????? 30 |
|? 10113 | 7345849 |?????? 14 |
|? 10008 | 5301964 |?????? 10 |
|? 10008 | 7868945 |?????? 10 |
|? 10068 | 7791370 |??????? 9 |
|? 10023 | 7103027 |??????? 5 |
|? 10113 | 7796603 |??????? 4 |
|? 10010 | 4068427 |??????? 4 |

MySQL [tuan]> show profiles;
+----------+------------+--------------------------------------------------------------------------------------------------+
| Query_ID | Duration?? | Query??????????????????????????????????????????????????????????????????????????????????????????? |
+----------+------------+--------------------------------------------------------------------------------------------------+
|??????? 1 | 0.00021225 | show profiles 6????????????????????????????????????????????????????????????????????????????????? |
|??????? 2 | 0.00020000 | show profiles for query 6??????????????????????????????????????????????????????????????????????? |
|??????? 3 | 0.10450975 | select *from `order` where MallID=10008 and UserId=3705695 order by CreateTimestamp desc limit 5 |
|??????? 4 | 0.00020725 | show profiles for query 6??????????????????????????????????????????????????????????????????????? |
|??????? 5 | 0.00089350 | select *from `order` where MallID=10008 and UserId=3705695 order by ID desc limit 5????????????? |
+----------+------------+--------------------------------------------------------------------------------------------------+
5 rows in set, 1 warning (0.01 sec)

MySQL [tuan]> show profile for query 3
??? -> ;
+----------------------+----------+
| Status?????????????? | Duration |
+----------------------+----------+
| starting???????????? | 0.000139 |
| checking permissions | 0.000031 |
| Opening tables?????? | 0.000051 |
| init???????????????? | 0.000102 |
| System lock????????? | 0.000028 |
| optimizing?????????? | 0.000040 |
| statistics?????????? | 0.000100 |
| preparing??????????? | 0.000037 |
| Sorting result?????? | 0.000027 |
| executing??????????? | 0.000021 |
| Sending data???????? | 0.000038 |
| Creating sort index? | 0.103652 |
| end????????????????? | 0.000069 |
| query end??????????? | 0.000027 |
| closing tables?????? | 0.000033 |
| freeing items??????? | 0.000094 |
| cleaning up????????? | 0.000022 |
+----------------------+----------+
17 rows in set, 1 warning (0.00 sec)

MySQL [tuan]> show profile for query 5;
+----------------------+----------+
| Status?????????????? | Duration |
+----------------------+----------+
| starting???????????? | 0.000137 |
| checking permissions | 0.000039 |
| Opening tables?????? | 0.000043 |
| init???????????????? | 0.000074 |
| System lock????????? | 0.000027 |
| optimizing?????????? | 0.000033 |
| statistics?????????? | 0.000105 |
| preparing??????????? | 0.000039 |
| Sorting result?????? | 0.000020 |
| executing??????????? | 0.000020 |
| Sending data???????? | 0.000177 |
| end????????????????? | 0.000023 |
| query end??????????? | 0.000026 |
| closing tables?????? | 0.000028 |
| freeing items??????? | 0.000083 |
| cleaning up????????? | 0.000021 |
+----------------------+----------+
16 rows in set, 1 warning (0.00 sec)

MySQL [tuan]>

同時看到使用的排序字段也有問題，使用 CreateTimestamp 排序性能與? ID 字段相比，直接差了100倍。所有的消耗都花在ORDER BY

這是因為MYSQL 的索引是BTREE，數據是按ID 大小進行排序的，如果你用ID 來排序，那就是物理順序，而使用了? CreateTimestamp ，那就得在

內存中重新排序。

修改后，再壓測試，達到他們的要求。

總結

以上是生活随笔為你收集整理的一个阿里云 MYSQL 服务 RDS 下的查询优化的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。