UPDATE/DELETE 慢主因是 WHERE 未走索引，执行计划 key 为空；需用 EXPLAIN 分析，避免函数、类型转换，改用范围查询，加 LIMIT 分批，检查引擎与统计信息。
UPDATE/DELETE 语句没走索引，执行计划里 key 是空的
这类操作慢，90% 是因为 where 条件没命中索引。mysql 的 update 和 delete 同样依赖执行计划，但很多人只在 select 上用 explain，忘了对修改语句也得查。
实操建议：
- 把
UPDATE或DELETE语句复制进 Navicat 查询编辑器，选中后点「解释」（Ctrl+E）——它会自动转成EXPLAIN UPDATE ...或EXPLAIN DELETE ...，别手动加SELECT包裹 - 重点看
type列：出现ALL或index就是全表/全索引扫描；rows值如果远大于你要改/删的实际行数，说明优化器没选对路径 -
possible_keys有值但key为空？说明索引存在，但字段顺序、隐式类型转换或函数包裹（如WHERE DATE(create_time) = '2023-01-01'）让索引失效
WHERE 条件用了函数或表达式，导致索引完全失效
对索引字段用函数是最常见的坑，比如 UPDATE users SET status = 1 WHERE YEAR(created_at) = 2023。这种写法 MySQL 无法使用 created_at 上的索引，只能全表扫。
实操建议：
- 改成范围查询：
WHERE created_at >= '2023-01-01' AND created_at - 避免隐式转换：
WHERE user_id = '123'（user_id是 INT）会触发类型转换，改用WHERE user_id = 123 - 复合索引要注意最左前缀：如果索引是
(status, created_at)，但条件只写了WHERE created_at > NOW()，那这个索引基本没用
批量更新/删除时锁表或事务太长，阻塞其他操作
一条 UPDATE 扫描几百万行，不仅慢，还会长时间持有行锁甚至表锁（尤其 MyISAM），其他查询全卡住。Navicat 默认不显示锁等待，容易误判为“只是慢”，其实是被堵住了。
实操建议：
- 加
LIMIT分批执行：UPDATE orders SET paid = 1 WHERE status = 'unpaid' LIMIT 1000，循环跑直到影响行为 0 - 确认引擎类型：InnoDB 支持行级锁，MyISAM 是表锁，大更新前先
SHOW CREATE TABLE xxx看引擎 - 别在 Navicat 里开长事务跑大更新——关掉「自动提交」后没手动
COMMIT，锁会一直挂着；建议用脚本或命令行工具控制事务边界
Navicat 自身设置放大了慢操作的感知延迟
不是 SQL 慢，而是 Navicat 在等结果、渲染、高亮或补全时卡住，尤其当 UPDATE 影响行数巨大但没 LIMIT，它会试图拉取所有受影响行的元数据（比如自增 ID 变化），造成界面假死。
实操建议：
- 执行前加
SELECT ROW_COUNT()预估影响行数，心里有底再跑 - 禁用「查询结果自动格式化」和「语法高亮」：设置 → 常规 → 查询编辑器 → 取消勾选「启用语法高亮」「自动格式化 SQL」
- 避免在结果集窗口右键「复制为 INSERT 语句」之类操作——这些功能会在后台偷偷查 schema，大表上极易卡顿
rows 和实际匹配数相差几十倍的 UPDATE/DELETE。这往往意味着统计信息过期，ANALYZE TABLE 比调索引还管用。别跳过这步。
