删除重复行时，最稳妥的方式是借助CTE与ROW_NUMBER()函数标记重复组，仅删除行号大于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是有效值（如库存为零），不能盲目删除 - 极值处理建议用
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%的数据。
