返回

数据库优化之殇：主键更新为何耗时10秒？**

后端

数据库优化，尤其是SQL语句优化，一直是运维和开发工程师面临的挑战。本文将记录一个真实项目中主键更新耗时10秒的排查历程，分享经验教训，供数据库优化人员参考。

问题

在一个线上业务系统中，有一个经常使用的更新操作：根据主键更新一条记录。然而，在某次部署后，该操作的耗时突然飙升至10秒以上。

排查过程

1. 分析explain结果

首先，我们使用explain分析了该SQL语句：

EXPLAIN UPDATE table_name SET field1 = 'value1', field2 = 'value2' WHERE id = 1;

explain结果如下：

| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
|---|---|---|---|---|---|---|---|---|---|
| 1 | SIMPLE | table_name | ALL | PRIMARY | NULL | NULL | NULL | 1000 | Using where; Using index; Using temporary; Using filesort |

从explain结果可以看出，该语句使用了全表扫描（type=ALL），而不是预期的主键索引（PRIMARY）。

2. 检查索引

接下来，我们检查了主键索引的定义：

SHOW INDEX FROM table_name;

结果显示，主键索引的定义是正确的，并且索引状态正常。

3. 检查数据分布

我们怀疑数据分布不均匀可能导致全表扫描。于是，我们对主键id字段进行了分布分析：

SELECT id, COUNT(*) AS count FROM table_name GROUP BY id;

结果显示，数据分布相对均匀，没有明显倾斜。

4. 检查统计信息

最后，我们检查了主键id字段的统计信息：

SHOW STATS_HEALTH FROM table_name;

结果显示，统计信息是最新的，没有问题。

解决方法

经过一番排查，我们最终发现问题出在该表的另一个索引上。这个索引是针对一个非唯一字段创建的，而且数据分布不均匀。当主键更新操作执行时，该索引也会被使用，导致额外的I/O开销和全表扫描。

于是，我们对该索引进行了优化，将数据分布不均匀的非唯一字段从索引中移除了。优化后，主键更新操作的耗时恢复正常。

总结

通过本次排查，我们总结了以下经验教训：

  • 遇到SQL语句性能问题时，首先要分析explain结果。
  • 检查索引定义和数据分布，排除索引失效或数据分布不均匀的问题。
  • 定期检查统计信息，确保其是最新的。
  • 优化非唯一索引，避免索引失效和全表扫描。