性能变差是因为缺少覆盖所有WHERE列的复合索引，单列索引无法高效支持多列组合条件；需按等值列优先、范围列靠后顺序创建联合索引，并避免函数操作导致索引失效。
UPDATE 语句中用多列作为 WHERE 条件时，为什么性能突然变差？
因为数据库无法自动利用单列索引加速多列组合条件——除非你显式创建了覆盖所有 WHERE 列的复合索引。比如 UPDATE orders SET status = 'shipped' WHERE user_id = 123 AND order_date = '2024-05-01'，若只有 user_id 索引或只有 order_date 索引，查询优化器大概率走全表扫描。
实操建议：
- 按 WHERE 子句中列的出现顺序建复合索引，例如
CREATE INDEX idx_user_date ON orders(user_id, order_date) - 把等值条件列放在索引前列（如
=），范围条件列（如>、BETWEEN）放后面 - 避免在索引列上用函数或表达式：
WHERE DATE(order_date) = '2024-05-01'会让索引失效，改用WHERE order_date >= '2024-05-01' AND order_date < '2024-05-02'
用 INSERT ... ON DUPLICATE KEY UPDATE 替代 UPDATE + SELECT？
当你的“多列组合唯一键”已定义为 UNIQUE 约束（如 UNIQUE (user_id, product_id)），且目标是“存在则更新，不存在则插入”，INSERT ... ON DUPLICATE KEY UPDATE 是原子且高效的方案；但注意它只响应违反该唯一约束的冲突，不是通用的“多列条件更新”替代品。
常见错误现象：
- 执行
INSERT INTO cart (user_id, product_id, qty) VALUES (101, 202, 5) ON DUPLICATE KEY UPDATE qty = qty + 5报错：没有定义对应唯一键 → 先确认SHOW CREATE TABLE cart中是否存在UNIQUE KEY `uk_user_prod` (user_id, product_id) - 误以为能匹配任意 WHERE 条件 → 它只对触发唯一约束冲突的行生效，不支持
WHERE a=1 AND b=2这类无约束的逻辑 - MySQL 8.0+ 支持
INSERT ... ON CONFLICT DO UPDATE（PostgreSQL 风格），但需开启兼容模式或直接用原生语法
UPDATE JOIN 写法在多列条件下的实际表现如何？
当你需要根据另一张表的多列结果来更新当前表（比如“把订单状态同步为最新发货单的状态”，关联字段是 (order_id, shipment_seq)），UPDATE ... JOIN 比子查询更可控、更容易命中索引。
使用场景与要点：
- 确保 JOIN 条件中的列在被驱动表上有联合索引，例如
UPDATE orders o JOIN shipments s ON o.order_id = s.order_id AND o.shipment_seq = s.seq→shipments表需有(order_id, seq)复合索引 - 避免在 JOIN 条件里写
s.status IS NOT NULL这类非等值过滤，它可能让索引失效；应先过滤再 JOIN，或改用EXISTS - PostgreSQL 不支持
UPDATE ... FROM的多列等值 JOIN 语法，得用USING或子查询，且USING (col1, col2)要求两表字段名完全一致
WHERE 中多个列都用 IN 时，索引还有效吗？
无效。像 WHERE user_id IN (1,2,3) AND order_date IN ('2024-05-01', '2024-05-02') 这种双 IN 组合，绝大多数数据库（MySQL/PostgreSQL）无法高效使用复合索引，会退化为 index range scan + 回表，甚至全索引扫描。
可选对策：
- 拆成多个单条 UPDATE（适合 IN 值少、数量稳定）：
UPDATE ... WHERE user_id = 1 AND order_date = '2024-05-01';× N - 用临时表承载条件集，再 JOIN 更新（适合 IN 值多、动态生成）：
CREATE TEMP TABLE batch_keys (user_id INT, order_date DATE); INSERT INTO batch_keys VALUES ..., ...; UPDATE orders o JOIN batch_keys b USING (user_id, order_date) SET o.status = 'done'; - 确认执行计划：
EXPLAIN FORMAT=JSON查看是否用了type: range还是type: ALL，别只看“key”字段显示有索引就放心
多列组合更新最常被忽略的点是：约束定义和索引定义必须严格对齐。比如唯一约束是 (a,b)，但你建了 (b,a) 索引，或者忘了加 NOT NULL 导致 MySQL 认为该约束不可用——这些都会让本该毫秒级的操作变成秒级甚至超时。
