单条记录UPDATE查询耗时超90秒，如何排查慢查询原因？

针对你遇到的仅匹配1条记录的UPDATE耗时超90秒的问题，可按以下步骤排查：

1. 验证WHERE条件的索引有效性 #

• 先通过执行计划确认查询是否走索引：

  EXPLAIN SELECT * FROM `tableA` WHERE `payment_no` = 'S00005303';
  

  如果type列显示为ALL，说明是全表扫描，未用到索引。
• 检查表上的索引情况：

  SHOW INDEX FROM `tableA`;
  

  确认payment_no字段是否有单列索引，或在复合索引中作为前缀列。同时注意字段类型与查询值类型是否一致（比如字段是varchar，查询不能用数字类型，避免隐式转换导致索引失效）。

2. 排查锁等待与未提交事务 #

• 查看当前锁等待状态：

  SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
  SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
  

  确认是否有其他事务持有目标行的行锁，导致UPDATE等待。
• 检查未提交的长事务：

  SELECT * FROM INFORMATION_SCHEMA.INNODB_TRX;
  

  即使show processlist看不到活跃查询，也可能存在未提交的事务残留锁。

3. 检查存储引擎与事务配置 #

• 确认表的存储引擎：

  SHOW CREATE TABLE `tableA`;
  

  如果是MyISAM，会使用表级锁，即使更新单条记录也会锁全表，若表数据量极大，锁表后的IO操作会非常耗时。
• 查看当前事务隔离级别：

  SELECT @@transaction_isolation;
  

  若为REPEATABLE READ，需确认是否因间隙锁导致额外等待（单条匹配记录的概率较低，但可排除）。

4. 检查服务器资源瓶颈 #

• 查看服务器CPU、内存、磁盘IO状态：
  • Linux下用top查看CPU使用率，iostat -x 1查看磁盘读写负载（若%util接近100%，说明磁盘IO饱和）。
• 检查数据库缓存命中率：

  SHOW STATUS LIKE 'Key_read%';
  

  计算Key_reads / Key_read_requests的比例，若比例过高（超过0.01），说明索引缓存命中率低，内存不足导致频繁读磁盘。

5. 检查表碎片与统计信息 #

• 检查表碎片情况：

  SHOW TABLE STATUS LIKE 'tableA';
  

  若Data_free字段值过大，说明表碎片严重，会增加UPDATE的IO开销。可在业务低峰执行OPTIMIZE TABLE tableA;整理碎片（注意该操作会锁表）。
• 刷新表统计信息：

  ANALYZE TABLE `tableA`;
  

  过时的统计信息可能导致优化器选择错误的执行计划，引发慢查询。

6. 排查触发器与外键约束 #

• 检查表上的触发器：

  SHOW TRIGGERS LIKE 'tableA';
  

  若存在BEFORE UPDATE或AFTER UPDATE触发器，需检查触发器内的逻辑是否存在耗时操作（如关联查询大表、复杂计算）。
• 检查外键约束：
  通过SHOW CREATE TABLE tableA;查看是否有外键，UPDATE时数据库会校验关联表的约束，若关联表无对应索引或数据量极大，会产生额外耗时。

内容的提问来源于stack exchange，提问作者Abdul Rahman.