UPDATE 语句没走索引，CPU 占用飙升
MySQL 的
UPDATE如果 WHERE 条件列没有索引，会触发全表扫描，尤其在大表上，不仅慢，还会锁住大量行（甚至整表），阻塞其他写操作。常见现象是
SHOW PROCESSLIST里看到状态为
Updating且
Time持续增长。 先确认执行计划：
EXPLAIN UPDATE users SET status = 'active' WHERE email = 'a@b.com';注意看
type是否为
ALL（全表扫描）或
range/
ref（走了索引）
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}'" 就是典型陷阱
索引不是加了就万事大吉，WHERE 条件的写法、参数类型、执行计划解读，三者缺一不可。线上执行前，一定在从库或测试环境跑 EXPLAIN，而不是靠“应该没问题”去赌。
