MySQL更新查询性能低下，是否为索引配置问题？

这种大数据量下的更新卡顿问题我碰到过不少，咱们一步步拆解瓶颈、优化性能：

1. 核心问题定位 #

你的更新语句在小数据量时正常，但10万+行时变慢，本质是索引利用率不足导致的全表/大范围扫描，加上accounts表的284万条目标数据无法高效匹配，最终拖慢了整个操作。

2. 优先级最高：给accounts表创建覆盖型复合索引 #

你的更新逻辑里，accounts表需要先过滤sa_partnerid = 118，再用sa_grp+sa_account关联_temp，最后只取sa_spid。单独的单列索引无法支撑这种多条件查询，建议创建覆盖复合索引：

CREATE INDEX idx_accounts_partner_grp_account_spid ON accounts(sa_partnerid, sa_grp, sa_account, sa_spid);

• 把过滤字段sa_partnerid放在最前面，直接缩小到284万条目标数据，避免扫描全表；
• 后续的sa_grp、sa_account用于快速关联匹配；
• 最后加入sa_spid做成覆盖索引，查询时不需要回表读取主键索引数据，直接从索引里拿到需要的sa_spid，大幅减少IO开销。

3. 优化_temp表的索引 #

_temp表需要先过滤g_spid IS NULL的待更新行，再关联g_group_norm+g_uid1，建议创建复合索引：

CREATE INDEX idx_temp_spid_group_uid ON _temp(g_spid, g_group_norm, g_uid1);

• 先通过g_spid IS NULL快速筛选出需要更新的行，避免扫描全表；
• 后续的关联字段直接从索引读取，减少匹配时间。

4. 分批更新（避免长时间锁表+超时） #

如果_temp表数据量接近70万，即使有索引，一次性更新也可能因为锁表时间过长、事务日志过大导致性能下降。改成小批量更新：

WHILE EXISTS (SELECT 1 FROM _temp WHERE g_spid IS NULL) DO
  UPDATE _temp T
  JOIN accounts A ON T.g_uid1 = A.sa_account AND T.g_group_norm = A.sa_grp
  SET T.g_spid = A.sa_spid
  WHERE A.sa_partnerid = 118 AND T.g_spid IS NULL
  LIMIT 1000; -- 每次更新1000行，可根据数据库性能调整
END WHILE;

• 小批量更新降低锁粒度，减少对业务的影响；
• 避免一次性生成过大的事务日志，缓解数据库IO压力。

5. 验证索引是否生效 #

优化后用EXPLAIN查看执行计划，确认索引被正确使用：

EXPLAIN UPDATE _temp T, accounts A SET T.g_spid = A.sa_spid WHERE T.g_uid1 = A.sa_account AND T.g_group_norm = A.sa_grp AND A.sa_partnerid = 118 AND T.g_spid IS NULL;

如果执行计划中type列显示ref或range，key列显示咱们创建的索引，说明优化生效。

内容的提问来源于stack exchange，提问作者Steve