syn*_*-dj 8 mysql myisam performance
在查看对 MyISAM 表执行多次需要很长时间的特别烦人的查询时，我注意到 MySQL 似乎暴露了一种相当奇怪的 I/O 模式：当执行单个查询并且必须执行一个重要的查询时I/O 量（例如，对于表扫描或当缓存为空时，echo 3 > /proc/sys/vm/drop_caches因此需要首先从磁盘加载索引），底层块设备的队列大小接近值 1，性能极差仅 4-5 MB/s：
root@mysql-test:~# iostat -xdm 5 /dev/sda
Linux 3.2.0-40-generic (mysql-test) 04/30/2014 _x86_64_ (4 CPU)
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.14 24.82 18.26 88.79 0.75 4.61 102.56 2.83 26.39 19.29 27.85 2.46 26.31
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 69.29 151.52 72.73 5.31 0.59 53.95 1.21 5.39 7.84 0.29 4.39 98.51
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 153.06 144.29 174.69 4.96 1.36 40.54 1.39 4.36 8.91 0.60 3.15 100.49
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 105.75 150.92 109.03 4.53 0.85 42.41 1.29 4.96 8.15 0.54 3.90 101.36
Device: rrqm/s wrqm/s r/s w/s rMB/s wMB/s avgrq-sz avgqu-sz await r_await w_await svctm %util
sda 0.00 48.89 156.36 51.72 5.28 0.76 59.38 1.28 6.16 8.02 0.55 4.77 99.23
虽然150个IOPS根本就什么单在给定的配置磁盘能够在随机I / O方面提供的，结果还是真的让我吃惊，因为我所期望的MySQL能够运行的异步I / O进行读取并取回大量块同时读取，而不是一个一个地读取和评估它们，有效地忽略了 RAID 配置中可用的并行化增益。什么设计决策或配置选项对此负责？这是特定于平台的问题吗？
虽然我已经用大型 MyISAM 表对此进行了测试，但我看到将相同表转换为 InnoDB 的类似效果（虽然还不错，但示例查询仍然需要 20-30 秒，大部分时间都花在读取磁盘上重新启动 mysql 守护程序后，队列长度为 1)，因此缓冲池为空。我还验证了同样的问题在 5.6 GA 和当前的 5.7 里程碑 14 上仍然存在 - 只要我使用单个查询线程，MySQL 似乎无法并行化查询处理所需的 I/O 操作。
根据请求，有关该场景的一些其他详细信息。可以使用多种查询类型观察该行为。我随意选择了一个进行进一步测试，其内容有点像这样：
SELECT herp.id, herp.firstname, herp.lastname, derp.label, herp.email,
(SELECT CONCAT(label, " (", zip_code, " ", city,")" ) FROM subsidiaries WHERE subsidiaries.id=herp.subsidiary_id ) AS subsidiary,
(SELECT COUNT(fk_herp) from herp_missing_data WHERE fk_herp=herp.id) AS missing_data
FROM herp LEFT JOIN derp ON derp.id=herp.fk_derp
WHERE (herp.fk_pools='123456') AND herp.city LIKE '%Some City%' AND herp.active='yes'
ORDER BY herp.id desc LIMIT 0,10;
我知道它有一些优化空间，但出于多种原因，我决定将其留在那里，并专注于为我看到的意外 I/O 模式寻找一般解释。
使用过的表中确实有一堆数据：
mysql> select table_name, engine, table_rows, data_length, index_length from information_schema.tables WHERE tables.TABLE_SCHEMA = 'mydb' and tables.table_name in ( 'herp', 'derp', 'missing_data', 'subsidiaries');
+-------------------------+--------+------------+-------------+--------------+
| table_name | engine | table_rows | data_length | index_length |
+-------------------------+--------+------------+-------------+--------------+
| derp | MyISAM | 14085 | 1118676 | 165888 |
| herp | MyISAM | 821747 | 828106512 | 568057856 |
| missing_data | MyISAM | 1220186 | 15862418 | 29238272 |
| subsidiaries | MyISAM | 1499 | 6490308 | 103424 |
+-------------------------+--------+------------+-------------+--------------+
4 rows in set (0.00 sec)
现在，当我在这些表上运行上面的查询时，我的执行时间超过 1 分钟，而系统显然一直忙于使用单个线程从磁盘读取数据。
示例查询执行的配置文件（在本例中花费了 1 分 9.17 秒）如下所示：
mysql> show profile for query 1;
+--------------------------------+-----------+
| Status | Duration |
+--------------------------------+-----------+
| starting | 0.000118 |
| Waiting for query cache lock | 0.000035 |
| init | 0.000033 |
| checking query cache for query | 0.000399 |
| checking permissions | 0.000077 |
| checking permissions | 0.000030 |
| checking permissions | 0.000031 |
| checking permissions | 0.000035 |
| Opening tables | 0.000158 |
| init | 0.000294 |
| System lock | 0.000056 |
| Waiting for query cache lock | 0.000032 |
| System lock | 0.000116 |
| optimizing | 0.000063 |
| statistics | 0.001964 |
| preparing | 0.000104 |
| Sorting result | 0.000033 |
| executing | 0.000030 |
| Sending data | 2.031349 |
| optimizing | 0.000054 |
| statistics | 0.000039 |
| preparing | 0.000024 |
| executing | 0.000013 |
| Sending data | 0.000044 |
| optimizing | 0.000017 |
| statistics | 0.000021 |
| preparing | 0.000019 |
| executing | 0.000013 |
| Sending data | 21.477528 |
| executing | 0.000070 |
| Sending data | 0.000075 |
| executing | 0.000027 |
| Sending data | 45.692623 |
| end | 0.000076 |
| query end | 0.000036 |
| closing tables | 0.000109 |
| freeing items | 0.000067 |
| Waiting for query cache lock | 0.000038 |
| freeing items | 0.000080 |
| Waiting for query cache lock | 0.000044 |
| freeing items | 0.000037 |
| storing result in query cache | 0.000033 |
| logging slow query | 0.000103 |
| cleaning up | 0.000073 |
+--------------------------------+-----------+
44 rows in set, 1 warning (0.00 sec)
首先让我澄清一下，MyISAM 不执行异步 I/O，但 InnoDB 在 MySQL 5.5 中默认执行并将执行。在 5.5 之前，它通过使用工作线程使用“模拟 AIO”。
我认为区分三种情况也很重要：
对于 (1) I/O 将能够为此并行执行。MyISAM 有一些限制：表锁定和保护key_buffer（索引缓存）的全局锁。MySQL 5.5+ 中的 InnoDB 在这里非常出色。
对于 (2)，目前不支持。一个很好的用例是分区，您可以在其中并行搜索每个分区表。
对于 (3) InnoDB 具有线性预读，如果读取了 56 个页面（这是可配置的），则可以读取整个范围（64 个页面的组），但还有进一步增强的空间。Facebook 已经写过关于在他们的分支中实现逻辑读头的文章（表扫描性能提高了 10 倍）。