UPDATE执行时先定位、加锁、写日志、再更新数据页，受引擎、索引和隔离级别影响；未走索引易致锁升级甚至全表扫描。
UPDATE 语句执行时到底发生了什么
MySQL 执行 UPDATE 不是简单地“改一行”，而是先定位、再加锁、再写日志、最后更新数据页。整个过程受存储引擎、索引、事务隔离级别共同影响。
常见错误现象：UPDATE 卡住、被阻塞、甚至触发全表扫描导致锁表——往往是因为没走索引或 WHERE 条件不精确。
- 必须确保
WHERE中的字段有有效索引，否则 InnoDB 会升级为行锁 → 表级锁（尤其在 RR 隔离级别下） - 避免在
WHERE中对字段做函数操作，比如WHERE YEAR(created_at) = 2024，这会让索引失效 - 批量更新尽量用主键或唯一索引定位，不要依赖非唯一二级索引（可能引发间隙锁冲突）
- 如果只更新少量字段，优先用
UPDATE ... SET col = ? WHERE pk = ?，避免无谓的字段重写和 undo 日志膨胀
DELETE 语句为什么比 SELECT 慢得多
DELETE 不仅要查数据，还要释放空间、维护索引、生成 undo/redo 日志，并可能触发外键检查与触发器。InnoDB 中删除不是物理擦除，而是标记为“可复用”，后续插入才可能覆盖。
典型问题：大表 DELETE 耗时长、磁盘 I/O 飙升、主从延迟加剧。
- 永远不要在没有
WHERE的DELETE FROM t上操作大表；清空用TRUNCATE TABLE t（但注意它会重置自增计数器且不可回滚） - 分批删除更安全：
DELETE FROM orders WHERE status = 'cancelled' ORDER BY id LIMIT 1000;
配合循环执行，每次提交事务，避免长事务拖慢 MVCC - 确认是否真需要删除：归档旧数据到历史表（
INSERT INTO archive_orders SELECT ...+DELETE）通常比直接删更可控 - 删除后若空间未回收，可能是
innodb_file_per_table = OFF或未执行OPTIMIZE TABLE（但该操作会锁表，生产慎用）
如何判断 UPDATE/DELETE 是否走索引
别猜，用 EXPLAIN 看执行计划。重点看 type、key、rows 和 Extra 字段。
鸿思特商城系统HstShop是一款B2C独立网店系统，由拥有十年互联网开发经验的牛头带队开发完成，完全免费开源，适合大中型网站平台快速构建立强大的网上商城平台网店系统。HstShop悉心听取每一位商家的需求与建议，根据中国人的购物习惯改进了购物流程，实现更好的用户购物体验。HstShop网店系统无论在产品功能、稳定性、执行效率、负载能力、安全性和搜索引擎优化等方面都居国内同类产品领先地位，成为国内
-
type = ALL表示全表扫描，危险信号 -
key = NULL表示没用上索引 -
rows值远大于实际匹配行数，说明索引选择性差或统计信息过期（可运行ANALYZE TABLE t更新） -
Extra出现Using where; Using index condition是理想状态；出现Using filesort或Using temporary则说明语句结构可能诱发额外开销
注意：对 UPDATE 和 DELETE 使用 EXPLAIN 时，MySQL 5.6+ 支持直接解释（如 EXPLAIN UPDATE ...），低版本需改写为等价 SELECT 分析。
高并发下 UPDATE/DELETE 的锁行为差异
InnoDB 对 UPDATE 和 DELETE 默认加 next-key lock（记录锁 + 间隙锁），目的是防止幻读。但两者的锁范围和持续时间不同。
-
UPDATE只锁满足WHERE条件的行（及对应间隙），但如果更新了索引列，还可能触发二级索引记录的锁升级 -
DELETE同样锁匹配行，但因涉及索引树结构调整，锁持有时间略长，尤其在唯一索引冲突检测时可能短暂升级为意向锁等待 - 显式加锁（
SELECT ... FOR UPDATE）后再UPDATE，比直接UPDATE更容易暴露死锁，因为前者提前占锁，后者在执行路径中才加锁 - 避免在事务中混合
UPDATE和DELETE操作同一张表的不同子集，极易因锁顺序不一致引发死锁
真正难调的从来不是语法对不对，而是锁怎么加、什么时候放、谁在等谁——这些细节藏在 INFORMATION_SCHEMA.INNODB_TRX 和 SHOW ENGINE INNODB STATUS 里。
