Question

我有大量行的MyISAM表 - 10M到500M。这些表用于不经常存储时间序列数据，我想为SELECT优化它，我正在通过2个索引进行优化：epoch和分类器列（包含几千个类别）。

我的问题是，我为特定类别做的第一个SELECT很长（10到50秒），而后续版本非常快，即使使用SQL_NO_CACHE也是如此。这样的查询通常会返回100,000到1M个元素。

分析表明MySQL花费了大量时间＆＃34;发送数据＆＃34;。这表明花费了很多时间来完成磁盘I / O.但我真的不明白瓶颈在哪里：

BTREE的瓶颈是读过吗？该树只有几千个节点，然后在所选节点中少于1M点。我不敢相信在现代机器上做这件事需要30秒，即使使用旧式硬盘也是如此。
是否正在读取表格中的行？这也是不到一百万行，平均长度约为40字节。
我不记得的其他东西？

以下是查询结果：

mysql> SELECT SQL_NO_CACHE COUNT(`Time`) FROM archive_1 WHERE Channel=63;
+---------------+
| COUNT(`Time`) |
+---------------+
|        450619 |
+---------------+
1 row in set (28.67 sec)

mysql> SELECT SQL_NO_CACHE COUNT(`Time`) FROM archive_1 WHERE Channel=63;
+---------------+
| COUNT(`Time`) |
+---------------+
|        450619 |
+---------------+
1 row in set (2.20 sec)

mysql> SELECT SQL_NO_CACHE COUNT(`Time`) FROM archive_1 WHERE Channel=63;
+---------------+
| COUNT(`Time`) |
+---------------+
|        450619 |
+---------------+
1 row in set (0.88 sec)

mysql> SHOW PROFILES;
+----------+-------------+-----------------------------------------------------------------------------------+
| Query_ID | Duration    | Query                                                                             |
+----------+-------------+-----------------------------------------------------------------------------------+
|        1 | 28.66720725 | SELECT SQL_NO_CACHE COUNT(`Time`) FROM archive_1 WHERE Channel=63 |
|        2 |  2.19872350 | SELECT SQL_NO_CACHE COUNT(`Time`) FROM archive_1 WHERE Channel=63 |
|        3 |  0.87811475 | SELECT SQL_NO_CACHE COUNT(`Time`) FROM archive_1 WHERE Channel=63 |
+----------+-------------+-----------------------------------------------------------------------------------+
3 rows in set (0.00 sec)

mysql> SHOW PROFILE FOR QUERY 1;
+----------------------+-----------+
| Status               | Duration  |
+----------------------+-----------+
| starting             |  0.000113 |
| checking permissions |  0.000010 |
| Opening tables       |  0.000027 |
| System lock          |  0.000017 |
| init                 |  0.000030 |
| optimizing           |  0.000018 |
| statistics           |  0.055731 |
| preparing            |  0.000024 |
| executing            |  0.000008 |
| Sending data         | 28.611161 |
| end                  |  0.000019 |
| query end            |  0.000005 |
| closing tables       |  0.000014 |
| freeing items        |  0.000021 |
| logging slow query   |  0.000003 |
| logging slow query   |  0.000004 |
| cleaning up          |  0.000005 |
+----------------------+-----------+
17 rows in set (0.00 sec)

mysql> SHOW PROFILE FOR QUERY 2;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000105 |
| checking permissions | 0.000011 |
| Opening tables       | 0.000036 |
| System lock          | 0.000015 |
| init                 | 0.000028 |
| optimizing           | 0.000019 |
| statistics           | 0.032255 |
| preparing            | 0.000024 |
| executing            | 0.000007 |
| Sending data         | 2.166140 |
| end                  | 0.000020 |
| query end            | 0.000004 |
| closing tables       | 0.000014 |
| freeing items        | 0.000025 |
| logging slow query   | 0.000003 |
| cleaning up          | 0.000018 |
+----------------------+----------+
16 rows in set (0.00 sec)

mysql> SHOW PROFILE FOR QUERY 3;
+----------------------+----------+
| Status               | Duration |
+----------------------+----------+
| starting             | 0.000071 |
| checking permissions | 0.000009 |
| Opening tables       | 0.000018 |
| System lock          | 0.000012 |
| init                 | 0.000021 |
| optimizing           | 0.000014 |
| statistics           | 0.000059 |
| preparing            | 0.000020 |
| executing            | 0.000007 |
| Sending data         | 0.877795 |
| end                  | 0.000021 |
| query end            | 0.000004 |
| closing tables       | 0.000015 |
| freeing items        | 0.000029 |
| logging slow query   | 0.000015 |
| cleaning up          | 0.000006 |
+----------------------+----------+
16 rows in set (0.00 sec)

我查询的特定表包含107,407,213行，数据长度为4,237,427,600字节，索引长度为4,255,541,248字节。我昨天优化了它，那时没有添加数据。

如果查询是I / O绑定的，我总是可以切换到SSD，我也可以选择将时间索引存储为整数而不是double。但到目前为止，我不明白我的瓶颈在哪里，我想在了解更多之前避免重大变化。

Answer 1

SQL_NO_CACHE意味着mysql不应该使用查询缓存。

仍然使用磁盘/缓冲区缓存，这就是为什么第一个查询需要更长时间，后续查询更快。

MySQL - 慢速访问表索引或表数据

1 个答案: