mysql多表更新没生效，主因是rows matched为0（join未匹配）或changed为0（值未变），需检查匹配条件、索引及子查询语法。
MySQL多表更新（UPDATE JOIN）执行后“没报错但数据没变”，绝大多数情况不是语法错误，而是逻辑匹配失败或条件误放——它根本没找到要更新的行。
UPDATE JOIN 没生效，先查 Rows matched 和 Changed
MySQL 的 UPDATE 返回两组数字：Rows matched（满足 WHERE + JOIN 条件的行数）和 Changed（实际字段值被修改的行数）。如果 Rows matched: 0，说明 JOIN 没匹配上任何行；如果 Rows matched: 100 但 Changed: 0，说明字段值本来就是你要设的值，MySQL 跳过了物理更新。
- 用命令行客户端执行后直接看返回信息；在程序里必须检查
mysql_affected_rows()（C）、cursor.rowcount（Python）等，不能只捕获异常 -
Changed == 0是合法状态，但业务上可能意味着参数传错、关联数据缺失，需主动告警而非静默忽略 - 测试时加
LIMIT 10（如UPDATE ... LIMIT 10），既能控制影响范围，又能快速验证是否真有匹配行
LEFT JOIN 更新时字段被设成 NULL，其实是 ON 或 WHERE 放错了
想更新主表所有行、对关联缺失的行设默认值，必须用 LEFT JOIN + IFNULL() 或 COALESCE()；但很多人把过滤条件全塞进 ON，导致语义变成“只更新有匹配且满足条件的行”，而误以为是 LEFT 行为。
- 错误写法：
UPDATE orders o LEFT JOIN customers c ON o.customer_id = c.id AND c.status = 'active' SET o.flag = 1→ 实际效果等同于INNER JOIN，c.status = 'active'在ON里会过滤掉不满足的右表行，左表未匹配行仍进入结果集，但c.status为 NULL，SET可能失效或设错值 - 正确写法：
UPDATE orders o LEFT JOIN customers c ON o.customer_id = c.id SET o.flag = IFNULL(c.is_vip, 0) WHERE c.id IS NOT NULL OR c.id IS NULL（后者冗余，LEFT JOIN 本身已覆盖全部左表） - 真正需要过滤时，
WHERE必须放在末尾，且区分清楚：驱动表条件（如o.created_at > '2025-01-01'）放 WHERE，关联补全逻辑（如IFNULL(c.discount, 0)）放 SET
JOIN 关联字段没索引，导致匹配不到或超时中断
MySQL 在 UPDATE JOIN 中对索引更保守——即使你建了索引，优化器也可能因预估成本高而弃用，直接走全表扫描。这时 Rows matched 可能极低，甚至因锁等待被 kill。
- 用
EXPLAIN FORMAT=TREE SELECT ...模拟等价查询（MySQL 8.0+），重点看type是否为ref或eq_ref，避免出现ALL或index -
orders.customer_id和customers.id必须各自有索引；外键约束 ≠ 索引，ALTER TABLE customers ADD INDEX idx_id (id)得显式执行 - 复合索引顺序必须匹配执行逻辑：等值条件字段（如
c.is_vip = 1）放最左，范围条件（如c.level > 5）居中，连接字段（如c.id）放最右 - 若
EXPLAIN显示右表type: ALL，立刻停手，先加索引再重试，别靠“多跑几次”硬扛
子查询嵌套在 SET 或 WHERE 里触发 Error 1093
这个错误常被误认为是 JOIN 问题，其实根源是：你在 SET 或 WHERE 中写了子查询，而该子查询又查了正在被 UPDATE 的同一张表。
- 错误示例：
UPDATE users SET last_login = (SELECT MAX(login_time) FROM users WHERE status = 'active')→ 直接报ERROR 1093 (HY000) - 绕过方法：子查询必须包一层派生表，并带别名，例如：
UPDATE users SET last_login = (SELECT max_time FROM (SELECT MAX(login_time) AS max_time FROM users WHERE status = 'active') AS tmp) - 更稳妥的做法是拆成两步：先
SELECT出值存到变量或临时表，再UPDATE时引用，尤其当子查询含聚合或复杂条件时 - 注意：派生表别名（如
AS tmp）不可省略，否则语法报错
真正难调试的不是语法报错，而是 Rows matched 和 Changed 都非零却业务结果不对——这时候得盯住 JOIN 条件是否真能命中、WHERE 是否意外过滤掉了本该更新的行、以及字段名有没有因未加表别名而歧义。别信“我写的肯定对”，先 SELECT 复现结果集再说。
