Question

我有一个包含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％的搜索时间> 1秒，所有查询中约有10％的搜索时间> 10秒（！）

可能导致此查询运行缓慢的原因是什么？据我所知，该计划是完美的，只扫描了一行，没有时间花在获取锁上。那是什么呢？

更新：忘记包含服务器规格，这是在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）组成的主索引。此外，这是一个只写主机，其他三个从机服务器处理所有读取。

Answer 1

我怀疑您正在更新的一个或多个列上有索引，并且使用那么大的索引，可能需要一些时间来刷新这些索引并重建必要的部分。我会对索引进行审核，并删除任何不会给您带来极高价值select性能提升的索引。快速搜索也出现了the delay-key-write option（仅限MyISAM： - /），这可能有所帮助。最后一个边界（如果这实际上是问题）将是查看master-for-write / slave-for-read架构，然后在写主服务器上执行明显更少的索引。

编辑我搜索了一些InnoDB选项，并找到this SO question关于如何暂时禁用它们进行写入操作的密钥。

即使正在使用主索引和良好的EXPLAIN计划，MySQL也会慢速查询

1 个答案: