Question

我们在整个数据库中的UPDATE性能偶尔会出现大幅放缓。

例如，表FooTable我们有大约40列varchar PK，另外还有10个索引。以下查询花了44秒，而在其他时候它几乎立即运行。在减速期间，服务器上的负载平均值非常低（5分钟平均值为1.5），而根据vmstat的IO也相当合理。

这是一个例子：

mysql> update FooTable set BarColumn=1349981286086 where varcharPK='e4348411-0fbb-460a-80f7-f1de304a9f7c'
Query OK, 1 row affected (44.94 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> show profile for QUERY 1;
+----------------------+-----------+
| Status               | Duration  |
+----------------------+-----------+
| starting             |  0.000030 |
| checking permissions |  0.000004 |
| Opening tables       |  0.000007 |
| System lock          |  0.000003 |
| Table lock           |  0.000003 |
| init                 |  0.000035 |
| Updating             | 44.949727 |
| end                  |  0.000006 |
| query end            |  0.000003 |
| freeing items        |  0.000115 |
| logging slow query   |  0.000002 |
| logging slow query   |  0.000052 |
| cleaning up          |  0.000003 |
+----------------------+-----------+
13 rows in set (0.02 sec)

值得一提的是，上面的示例查询是在InnoDB表上运行的，该表是在不到一周前的“重建”（ALTER TABLE FooTable ENGINE = InnoDB;）。我最初怀疑这与InnoDB已知的varchar /非顺序PK性能问题有关，但是我们有其他表使用顺序PK并且看到了相同的问题。

这是在生产服务器上： Centos 5 2.6.18-238.19.1.el5 x86_64 MySQL / Percona 5.1.57-rel12.8-log 内存为96GB，58.8G数据分布在87个表中

相关的InnoDB设置如下：

innodb_flush_log_at_trx_commit  = 2
innodb_buffer_pool_size         = 70G
innodb_log_file_size            = 512M
innodb_log_buffer_size          = 64M
innodb_file_per_table           = 1
innodb_thread_concurrency       = 0
innodb_flush_method             = O_DIRECT
innodb_read_io_threads          = 64
innodb_write_io_threads         = 64
optimizer_search_depth          = 0
innodb_file_format              = barracuda

我没有在这张桌子上使用FORMAT = COMPRESSED，但我在其他人身上。

关于如何弄清楚在更新阶段发生了多长时间的事情的任何建议？

Answer 1

根本原因似乎是长时间运行的应用程序事务。解决方案是将大型交易分解为较小的工作单元。

Answer 2

如何（在varcharPK-field上使用哈希索引将varcharPK转换为文本和？）

alter table FooTable添加KEY pk_index（varcharPK（100））使用HASH

我有过类似的问题，这有帮助。我不确定它会对你有所帮助。如果你可以分割表格，声音也会有所帮助 - 它有“太多”的数据。

MySQL / InnoDB偶尔会有一些更新在“更新”状态下运行得很慢

2 个答案: