update语句未走索引会导致全表扫描、cpu飙升和锁表；需用explain确认执行计划，为where列建索引，避免函数操作、隐式类型转换及错误引号使用，并在测试环境验证。
UPDATE 语句没走索引，CPU 占用飙升
MySQL 的 UPDATE 如果 WHERE 条件列没有索引，会触发全表扫描，尤其在大表上，不仅慢，还会锁住大量行（甚至整表），阻塞其他写操作。常见现象是 SHOW PROCESSLIST 里看到状态为 Updating 且 Time 持续增长。
- 先确认执行计划：
EXPLAIN UPDATE users SET status = 'active' WHERE email = 'a@b.com';
注意看type是否为ALL（全表扫描）或range/ref（走了索引） -
email字段若未建索引，立刻加：ALTER TABLE users ADD INDEX idx_email (email);
- 避免在 WHERE 中对字段做函数操作，比如
WHERE UPPER(email) = 'A@B.COM'会让索引失效；应统一存储规范，查询时直接比对原始值 - 批量更新时，别用单条
UPDATE循环，改用INSERT ... ON DUPLICATE KEY UPDATE或临时表 JOIN 方式，减少锁持有时间
DELETE 语句卡住、事务日志暴涨
DELETE FROM orders WHERE created_at 这类语句在千万级表上极易出问题：InnoDB 要逐行标记删除、写 undo log、维护 MVCC 版本链，还可能触发 buffer pool 淘汰风暴。
- 务必确保
created_at有索引，否则就是全表扫 + 全表删，不是“慢”，是“不可用” - 不要一次性删太多——超过 10 万行建议分批，例如：
DELETE FROM orders WHERE created_at < '2022-01-01' ORDER BY id LIMIT 10000;
配合循环执行，每次提交事务 - 如果只是清空旧数据且无需回滚，
TRUNCATE TABLE更快，但它会重置自增 ID、不能带 WHERE、需 DROP 权限，慎用 - 分区表适合按时间归档的场景，比如按月分区后，直接
ALTER TABLE orders DROP PARTITION p202112是毫秒级的
UPDATE/DELETE 中子查询导致性能雪崩
这类写法很常见但极其危险：
UPDATE logs SET status = 'archived' WHERE id IN (SELECT id FROM temp_archive_list);MySQL 5.6+ 虽优化了部分子查询，但依然可能生成临时表、无法使用外层索引，实际执行等价于嵌套循环。
- 优先改写为 JOIN：
UPDATE logs l JOIN temp_archive_list t ON l.id = t.id SET l.status = 'archived';
- 确保
temp_archive_list.id有索引（哪怕它是临时表，也要显式CREATE TEMPORARY TABLE ... INDEX） - 避免在子查询中用
NOT IN，NULL 值会导致结果为空集；改用NOT EXISTS或LEFT JOIN ... IS NULL - 子查询返回结果集过大（如 > 1 万行）时，JOIN 也可能变慢，此时应先将子查询结果导出到带主键的临时表再关联
隐式类型转换让索引彻底失效
这是最隐蔽也最常被忽略的问题。比如 user_id 是 BIGINT 类型，但你写了：
UPDATE users SET name = 'test' WHERE user_id = '12345';字符串常量触发隐式转换，MySQL 会把每行
user_id 转成字符串再比对，索引直接作废。
- 检查
EXPLAIN输出中的type和key字段，若key为NULL且type是ALL或index，大概率是类型不匹配 - WHERE 条件中，数值型字段必须用数字字面量（不带引号），字符串字段才用单引号
- 用
SELECT COLUMN_NAME, DATA_TYPE FROM INFORMATION_SCHEMA.COLUMNS核对字段类型，别依赖印象 - 应用层拼 SQL 时，注意 ORM 或模板引擎是否自动加了引号——例如 Python 的 f-string 写
f"WHERE id = '{uid}'"就是典型陷阱
EXPLAIN，而不是靠“应该没问题”去赌。 
