这种跨版本的批量更新坑我之前踩过！结合你描述的场景——本地MySQL 5.6单/批量都正常，生产RDS 5.5只有单ID正常、批量时a_string全变成string2，大概率是MySQL 5.5在批量更新时的字段引用逻辑bug导致的，咱们一步步来解决：

先排查你的SQL写法（最可能的原因） #

我猜你的批量更新SQL大概是这样的：

UPDATE your_table 
SET 
  status = 1 - status,
  a_string = CASE WHEN status = 1 THEN 'string1' ELSE 'string2' END
WHERE id IN (100, 101, 102);

问题出在：MySQL 5.5对批量UPDATE中字段的引用逻辑有bug——当用IN子句批量更新时，CASE/IF里的status并没有取到每条记录更新前的原始值，而是被优化成了同一个固定值（比如最后一条记录的status，或者某个默认值），导致所有行的a_string都被设成了string2。而MySQL 5.6修复了这个逻辑问题，所以本地正常。

解决办法：用JOIN子查询锁定原始值

把更新逻辑改成基于子查询获取每条记录的原始status，这样就能确保每条记录的判断都是独立的：

UPDATE your_table t1
JOIN (SELECT id, status FROM your_table WHERE id IN (100, 101, 102)) t2
ON t1.id = t2.id
SET 
  t1.status = 1 - t2.status,
  -- 这里直接用切换后的新状态判断，更稳妥
  t1.a_string = CASE WHEN (1 - t2.status) = 1 THEN 'string1' ELSE 'string2' END;

或者更清晰一点，先计算好新状态：

UPDATE your_table t1
JOIN (
  SELECT 
    id, 
    1 - status AS new_status 
  FROM your_table 
  WHERE id IN (100, 101, 102)
) t2 ON t1.id = t2.id
SET 
  t1.status = t2.new_status,
  t1.a_string = CASE WHEN t2.new_status = 1 THEN 'string1' ELSE 'string2' END;

这个写法在5.5和5.6里都能正常工作。

再检查sql_mode配置差异 #

本地和生产的sql_mode可能不一样，比如生产开启了严格模式，导致批量更新时的逻辑异常。你可以分别在本地和生产执行这条命令查看：

SELECT @@sql_mode;

如果生产的sql_mode包含ONLY_FULL_GROUP_BY、STRICT_ALL_TABLES这类本地没有的选项，可以临时调整试试（注意先确认业务影响）：

SET sql_mode = 'STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION';

测试批量更新正常后，再考虑在RDS参数组里永久修改配置。

长远方案：升级MySQL版本 #

MySQL 5.5已经停止官方支持好几年了，AWS RDS的5.5也早晚会退出维护。升级到5.6+或者更高版本，不仅能解决这类兼容问题，还能获得更好的性能和安全性。

内容的提问来源于stack exchange，提问作者JSP