【发布时间】：2011-08-10 07:29:59
【问题描述】：
我们有一个分区表，其中包含大约 200,000,000 行的 15 天数据。 （删除第 16 天，每天早上创建第 0 天。）
该表通常非常快，但有时可能非常慢，我想知道是否有人有任何发现问题/瓶颈的提示。
该表按“day”上的列表进行分区（使用“day-of-epoch”整数；今天 =~ 15100），并按另一个重要 id 的线性键进行子分区。 day 和 id 都以正确的顺序构成主键的一部分，并在查询中使用。
一个典型的查询可能只使用 360 个分区中的 6 个（通过修剪）。
让我感到困惑的是，虽然它通常以每秒约 350 多个查询的速度运行，但对于相同的查询，它有时会减慢到 2 qps...并且需要几分钟才能提取 100 个查询。
完全重启MySQL似乎并没有影响两个相似查询之间的任意速度差异，这让我认为问题一定与磁盘IO和磁盘缓存有关？
问题确实是；从哪里开始寻找？ MySQL，邦妮++？ ..
谢谢！
【问题讨论】：
-
只是一个意见：看看慢查询日志（如果它还没有激活，则激活它，并找到慢查询并对其运行解释，也许问题是一些缺少索引或类似的东西那）dev.mysql.com/doc/refman/5.1/en/slow-query-log.html
-
嗨，保罗，感谢您回复我。我有，是的。它表明这些小查询可以以大约（平均）2 秒的速度运行 [例如：# Query_time: 4.927696 Lock_time: 0.000087 Rows_sent: 489 Rows_examined: 489] 但它通常会完成 300 个相同的查询
-
几个问题。会减速多久？它在哪个操作系统上运行？当 MySQL 变慢时，操作系统正在运行的任何其他任务是否会出现活动峰值，或者所有速度的降低都归结为 MySQL？会不会是垃圾收集正在运行之类的。
-
@Jaydee 我一直在尝试使用包含 SQL_NO_CACHE 的终端中的原始查询。由于操作系统很少或什么都不做，第一次查询仍然很慢（> 2.5 秒）。再次运行它们，然后它们
-
Partition Key Distribution Chart/Data - 分区键分布的快速总结。一共170个分区，索引平均25MB，全表索引4GB……难道只是磁盘IO问题？
标签： mysql optimization query-optimization database-partitioning