2

我有一个 130 万行的高流量表，它看到了大量以下类型的慢查询：

UPDATE app_info SET data1=269223, data2=0, data3=164, last_update='2012-08-30'
WHERE slice_id=7636 AND app_id=375 AND user_id=21012286 AND mode_id=1;

然而，这个查询的解释计划表明了一个最佳计划（我们正在使用主键）：

explain select * from app_info
where slice_id=7636 and app_id=375 and user_id=21012286 and mode_id=1\G

*************************** 1. row ***************************
           id: 1
  select_type: SIMPLE
        table: app_info
         type: const
possible_keys: PRIMARY
          key: PRIMARY
      key_len: 18
          ref: const,const,const,const
         rows: 1
        Extra:

这是慢查询日志：

 Time: 120830  3:23:37
# User@Host: rest_service[rest_service] @ app01.peak.mindjolt.com [10.0.0.174]
# Thread_id: 10091395  Schema: platform  Last_errno: 0  Killed: 0
# Query_time: 68.559347  Lock_time: 0.000045  Rows_sent: 0  Rows_examined: 1 Rows_affected: 1  Rows_read: 2
# Bytes_sent: 52  Tmp_tables: 0  Tmp_disk_tables: 0  Tmp_table_sizes: 0
# InnoDB_trx_id: 575CBF3B9
UPDATE app_info SET data1=269223, data2=0, data3=164, last_update='2012-08-30' WHERE slice_id=7636 AND app_id=375 AND user_id=21012286 AND mode_id=1;

大约 30% 的查询耗时 >1s，大约 10% 的查询耗时 >10s (!)

什么可能导致此查询运行缓慢？据我所知，计划很完美，只扫描了一行，没有花时间获取锁。那么，会发生什么？

更新：忘记包含服务器规格，这是在 64G Quad Xeon X5650 2.66GHz（24 核）、Mysql 5.1.52-rel11.6-log Percona 服务器 11.6、12 磁盘 PERC H700 RAID 阵列上。该服务器已经运行了很长时间（正常运行时间表示 565 天）。

更新2：这个表只有一个索引，它是一个由元组（app_id，user_id，slice_id，mode_id）组成的主索引。此外，这是一个只写的主服务器，其他三个从服务器处理所有读取。

4

1 回答 1

2

我怀疑您正在更新的一个或多个列上有索引，并且索引如此之大，可能需要一些时间来刷新这些索引并重建必要的部分。我会对索引进行审计，并删除任何没有给你带来非常有价值的select性能提升的东西。快速搜索还发现了延迟键写入选项（仅限 MyISAM :-/），这可能会有所帮助。最后一个前沿（如果这确实是问题的话）是研究主写/从读架构，然后在你的写主服务器上做更少的索引。

编辑我搜索了一些 InnoDB 选项，发现了这个关于如何暂时禁用键以进行写操作的问题。

于 2012-08-30T04:40:27.423 回答