安全删除重复行需用cte+row_number()标记并删rn>1的行，全程包裹事务、预览验证、异常捕获，且partition by和order by须严格匹配业务去重与保留逻辑。
存储过程里怎么安全地删重复行
直接在存储过程中用 DELETE 删重复数据，最容易踩的坑是没加事务控制或没备份——一跑就丢数据。真正可用的写法必须带事务、带日志、带保留逻辑。
典型结构是：先用 ROW_NUMBER() 标记重复组，再只删 rn > 1 的行，且整个操作包裹在 BEGIN TRY...BEGIN CATCH 中。
- 必须用
WITH CTE AS (...)定义临时结果集，不能直接对原表DELETE FROM table WHERE ...套子查询——SQL Server 不允许对含聚合/窗口函数的视图直接删 -
PARTITION BY的列要和业务去重标准严格一致，比如按customer_id, order_date去重，就不能漏掉任一列 -
ORDER BY必须明确指定保留哪条，例如ORDER BY created_time DESC保留最新记录；用(SELECT NULL)虽语法合法，但结果不可控，线上环境禁止使用 - 执行前建议先
SELECT出待删的行做验证：SELECT * FROM CTE WHERE rn > 1
清洗乱码和无效值该不该放同一个存储过程里
可以放，但必须分步、可开关、有标记。把去重、删乱码、剔零值、截极值全塞进一个存储过程，表面省事，实际维护时根本没法定位问题。
更合理的做法是：每个清洗动作独立成块，用参数控制是否启用，并记录每一步影响行数。
- 判断乱码优先用
ISNUMERIC(value) = 0，但注意它对带符号或小数点的字符串也返回 1，所以后续还需TRY_CAST(value AS float) IS NULL二次校验 - 删
value = 0前确认业务语义：有些场景 0 是有效值（如库存为 0），不能无脑删 - 极值处理建议用
PERCENTILE_CONT或提前算好阈值存配置表，避免硬编码WHERE value > 10000这类魔法数字 - 每步执行后用
@rows_affected = @@ROWCOUNT记录日志，方便回溯哪步清掉了多少数据
为什么不能用 DISTINCT + SELECT INTO 替代去重逻辑
因为 SELECT DISTINCT * INTO #temp 看似简单，但在存储过程中会引发三类硬伤：丢失标识列、破坏约束、无法控制保留哪条重复记录。
尤其当原表有 IDENTITY、DEFAULT、CHECK 或外键时，这种“重建表”式去重等于绕过所有数据完整性保障。
-
SELECT DISTINCT *无法指定保留逻辑——比如同一客户多条订单，你想要最新那条，它随机留一条 -
INTO新表不会继承原表的索引、触发器、权限，后续还得手动补，容易遗漏 - 如果表有计算列或稀疏列，
SELECT *可能报错或静默丢列 - 大表执行时会锁全表，而
CTE + DELETE可配合TOP (N)分批执行，降低阻塞
存储过程里怎么防止下次再写入重复数据
去重是救火，加约束才是防火。存储过程执行完去重后，必须紧接着检查并创建唯一约束，否则下一批数据照旧重复。
但别直接 CREATE UNIQUE INDEX ——如果已有重复，命令会失败。得先确保数据干净，再建约束。
- 建约束前务必验证：
SELECT COUNT(*) FROM table GROUP BY col1, col2 HAVING COUNT(*) > 1返回 0 才能继续 - 推荐用
CREATE UNIQUE INDEX IX_table_col1_col2 ON table(col1, col2) WHERE col1 IS NOT NULL AND col2 IS NOT NULL，带过滤条件避免 NULL 冲突 - 约束名要规范，比如
UQ_orders_customerid_orderdate，方便后续排查 - 如果业务允许部分重复（如历史归档表），至少加个
INSERT触发器做轻量级拦截，比应用层校验更可靠
真正难的不是写出能跑的存储过程，而是让每次执行都可预期、可审计、可回滚。字段组合变了、保留规则调了、新来了 NULL 值——这些细节不显眼，但足以让一个“稳定运行半年”的清洗过程突然删掉 80% 的数据。
