SQL 如何处理历史数据修正？

MySQL中UPDATE带子查询易改错行，因子查询未关联主表导致全表设同值；正确解法是用INNER JOIN显式关联并精确ON匹配。

UPDATE 带子查询时，为什么总改错行？

MySQL 中直接在 UPDATE 里嵌套不带关联的子查询（比如 SET x = (SELECT y FROM t)），极大概率会把所有行都设成同一个值——因为子查询没绑定到当前更新行，数据库只能取“任意一行”或报错（取决于 SQL 模式）。这是历史数据批量修正中最常踩的坑。

• 错误写法：UPDATE gy_sorter_info SET carbon_brush_num = (SELECT CEIL(COUNT(*)/24) FROM sorter_equipment_relation r WHERE r.sorter_code = gy_sorter_info.code) → 实际执行时，gy_sorter_info.code 在子查询中不可见，MySQL 会报错或返回空/默认值
• 正确解法：必须用 INNER JOIN 把目标表和计算结果显式关联，确保每行更新只取对应计算值
• 关键点：子查询结果必须含能与主表匹配的字段（如 id 或业务主键），且 ON 条件要精确对齐

按时间范围批量修正，WHERE 条件怎么写才安全？

修正某段时间内录入错误的数据（比如 2 小时内价格填反、状态误设），核心是精准圈定范围，避免波及其他数据。别信“大概时间”，得靠字段真实值说话。

• 优先用带时区的 DATETIME 或 TIMESTAMP 字段，例如：WHERE created_at BETWEEN '2026-01-22 14:00:00' AND '2026-01-22 16:00:00'
• 如果只有日期字段（如 DATE 类型），用 >= '2026-01-22' AND 更可靠，避免 BETWEEN 对时间精度的隐式截断
• 务必先跑 SELECT COUNT(*) 验证范围：SELECT COUNT(*) FROM orders WHERE status = 'pending' AND updated_at BETWEEN ... —— 数量不对就停手，别急着 UPDATE

用视图更新数据，哪些操作会被静默拒绝？

视图不是万能代理，它背后是多个基表时，SQL Server 或 MySQL 会限制写入行为。你以为改的是视图，其实数据库在判断“这行到底属于哪张表”。

• 只允许 UPDATE 单一基表中的列；若视图 JOIN 了三张表，你改其中一张的字段可以，但试图同时改两张表的字段会失败
• INSERT 必须满足：所有 INSERT 列都来自同一张基表，且该

  

  表其他非空列有默认值或你在语句中提供了值
• 删除（DELETE）基本不可行——只要视图涉及多表 JOIN，数据库通常直接报错 View's SELECT contains a JOIN
• 实操建议：查 sys.views（SQL Server）或 INFORMATION_SCHEMA.VIEWS 确认视图定义，比盲目尝试更省时间

修正前不备份，等于在生产库上玩俄罗斯轮盘

所有修正脚本上线前，必须完成三件事：备份、测试、记录。这不是流程主义，是防止 WHERE 写错一个条件就全表覆灭的底线。

• 备份不是“导出 Excel”——要用 mysqldump --where="id IN (...)" 或 pg_dump -t table --inserts 生成可重放的 SQL 片段
• 测试必须在同结构、同数据量的预发环境跑，重点看执行计划（EXPLAIN UPDATE ...）是否走索引，避免全表扫描锁表
• 每条修正语句旁加注释说明影响范围，例如：-- 修正 2025Q4 所有 status=2 的订单，共约 1.2w 行，已确认无外键依赖

真正危险的不是语法错误，而是逻辑正确但范围失控——比如漏写 AND tenant_id = 123，让租户 A 的数据被租户 B 的规则覆盖。这种问题不会报错，只会悄悄腐烂。