向MySQL官方提供的第一个bug，并被verified，记录一下
bug链接：bugs.mysql.com/bug.php?id=…
不得不说，官方回复的速度很赞
问题发现的背景是，线上会监控io wait summary表（ table_io_waits_summary_by_table和table_io_waits_summary_by_index_usage ）来监控表访问及DML的趋势变化，但是对于分区表却发现有和实际不一致的情况。
实际上，看到也有其他人遇到同样的场景，但是官方却并没有人提bug：forums.percona.com/t/table-io-…
于是，经过测试及验证，得出以下的结论（这是一个总结篇，有兴趣可自行验证...）
对于分区表， table_io_waits_summary_by_table和table_io_waits_summary_by_index_usage 表的count_xxx在一些情况下不计数（详细测试记录见bug链接），目前测试出来的表现如下：
- 使用二级索引/主键范围查询、in()多个value的情况不计数
- 使用二级索引/主键等值查询、in()一个value的情况正常计数
- 不使用索引的情况正常计数
对于普通表， table_io_waits_summary_by_table和table_io_waits_summary_by_index_usage 表的count_xxx正常计数，有如下的规律：
- count_select/count_fetch 表示的是扫描的行数而不是返回的行数
- count_update表示的是matched的行数而不是changed的行数，update会导致count_fetch增加
- count_delete表示的是实际删除的行数，会导致count_fetch增加
- count_insert表示insert的行数，不会导致count_fetch增加
- insert on duplicate key update 如果数据已经存在，则count_update/count_insert/count_fetch均会增加，否则只增加count_insert
- replace into 如果数据存在，count_update/count_insert/count_fetch均会增加，否则只增加count_insert
- update/delete如果走索引且在索引上没有匹配到行，count_fetch会增加1，不会增加count_update/count_delete（如果需要回表则和count_fectch扫描的二级索引记录数有关）
- select走索引但是在二级索引上没有匹配到行，不增加计数，即空扫描不计数（如果需要回表则和扫描的二级索引记录数有关）
- select没有走索引没有匹配到行，count_fetch增加的行数为全表扫描的行数
