DataGrip复制Aurora表后.NET在AWS环境遇EF乐观并发异常

一、触发乐观并发异常的直接原因 #

• DataGrip迁移的并发字段值异常：EF的乐观并发依赖Timestamp/RowVersion这类并发标记字段，DataGrip的「Copy To...」命令可能没正确复制这类字段的原始二进制值——要么生成了新值，要么目标库的字段类型、默认值设置和源库不一致。比如源库的RowVersion是自动生成的二进制，DataGrip复制时把它当成普通二进制写入，导致EF上下文跟踪的旧值和数据库实际值不匹配，更新时WHERE条件找不到对应行，就会报“预期影响1行实际0行”的异常。
• 目标表结构不匹配：迁移后目标表的主键、索引或约束和源库有差异，比如源库是复合主键，目标库只建了单主键，EF生成的UPDATE语句WHERE条件无法匹配唯一行；或者索引缺失导致更新时行匹配逻辑出错。

二、本地与AWS环境表现差异的深层原因 #

• 数据库会话参数不一致：本地通过堡垒机连接时，客户端可能自动设置了sql_mode、character_set等会话参数，和ECS Fargate中应用连接数据库的参数不一样。比如目标库sql_mode开了STRICT_TRANS_TABLES，本地没开，EF生成的SQL在本地能正常匹配行，到ECS环境就因为字段类型隐式转换失败，WHERE条件不生效。
• EF上下文跟踪状态差异：本地调试时EF上下文是短生命周期，跟踪严格；ECS环境中可能用了长生命周期上下文，或者缓存复用导致实体的并发标记字段值过期。另外本地可能查完最新实体就立即更新，ECS环境可能从缓存拿旧实体，自然会出现并发标记不匹配。
• Aurora读写分离路由问题：如果目标是Aurora集群，本地连的是主节点，而ECS应用的连接字符串配了只读节点或读写分离端点，更新操作被路由到只读节点，根本写不进去，EF就会把这种情况捕获成乐观并发异常。
• 网络延迟引发的并发冲突：ECS环境中应用和数据库的网络延迟更高，EF加载实体到执行更新的间隙里，可能有其他操作（比如迁移残留脚本、其他服务）修改了目标行的并发标记；本地网络快，这个间隙极短，不会触发冲突。

三、验证与修复建议 #

• 检查并发字段：对比源库和目标库的RowVersion/并发字段值，用SELECT HEX(row_version_column) FROM table WHERE id = ?查看十六进制值是否一致，确认DataGrip复制的是原始值。
• 核对表结构：确保目标表的主键、索引、约束（包括RowVersion字段的DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP属性）和源库完全一致。
• 统一连接参数：在ECS应用的连接字符串里显式设置sql_mode、character_set_client等参数，和本地用的保持一致。
• 确认Aurora端点：保证ECS应用连接的是Aurora主节点端点，不是只读端点。
• 规范EF上下文：ECS环境中把EF上下文设为请求级别的短生命周期，避免实体跟踪过期。

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