[[数据清洗]] [[SQL学习笔记]]
做数据分析最烦的，很多时候不是建模，也不是画图，而是前面的脏活：洗数据。
姓名前后带空格，手机号混着短横线和区号，日期一会儿是 2026-04-01，一会儿又变成 2026/04/01。你要是不先把这些问题处理掉，后面的统计口径、指标分析、画像建模，基本都会歪。
很多人一提数据清洗，第一反应就是 Python。可在大量日常场景里，SQL 其实更直接：离数据近、处理快、适合批量操作，很多问题在库里顺手就能解决。
这篇我不讲虚的，直接给你 20 段我觉得最常用、最值得收藏的 SQL 数据清洗代码。不是冷门技巧大全，而是高频实战清单。
先说清楚两点：
-
✅ 文中 SQL 我已经按 SQLite 3.51.0 在本机逐条执行验证通过。
-
⚠️ 如果你线上用的是 MySQL、PostgreSQL、SQL Server 或 Oracle，函数名和日期处理写法可能需要按数据库方言微调后再上线。
1）去掉字段首尾空格
这个问题太常见了。姓名、部门名、商品名、证件号，导入 Excel 或人工录入后，经常前后带空格。
如果你想直接更新原表：
2）把空字符串统一成 NULL
很多系统表面上“不是空值”，其实存的是空字符串。后面统计缺失值时，这种数据最烦。
这个动作做完，后面再算缺失率就干净多了。
3）替换特殊字符
有些字段里会混进换行、回车、全角空格，肉眼不一定看得出来，但分组统计时就会出问题。
如果是备注字段，这一步尤其值得先做。
4）统一大小写
邮箱、工号编码、课程代码这类字段，经常一部分大写、一部分小写。后面做匹配时，不统一就容易丢数据。
5）修正日期格式
同一张表里日期格式不统一，是最常见的数据源问题之一。
这段适合处理 2026/04/01 和 2026-04-01 这类常见混用格式。
6）统一性别字段口径
这个场景你肯定见过：男 / 女 / M / F / 1 / 2 / 未知 / 空值 混在一起。
这种字段一定要尽早标准化，不然后面画像分析会非常难受。
7）补默认值
有些缺失值不适合一直保留 NULL，比如状态字段、标志字段。
如果是数值字段，也可以这样写：
8）去重：保留最新一条记录
这一段我真的高频用。
同一个用户、同一个订单、同一个学生，重复导入多次是非常常见的问题。很多人第一反应是 distinct，但真正好用的，往往是窗口函数。
你只要把“按谁分组”和“按什么排序保留最新”换掉，就能处理很多重复数据问题。
9）找出重复记录
不是所有重复都要直接删，很多时候要先查出来给业务确认。
这段特别适合先做巡检。
10）手机号标准化和脱敏
手机号经常带空格、短横线，甚至前面带区号。
如果你要展示脱敏结果：
11）身份证号校验长度
身份证号这种字段，最基本的一步就是先查长度异常。
先把明显错的筛出来，再谈后面的年龄、性别解析。
12）从身份证号提取出生日期
如果身份证号质量还可以，这一步很方便。
⚠️ 这段依赖身份证号本身真实有效，不能把它当成绝对正确的数据源。
13）计算年龄分层
年龄不是直接存的，通常要从出生日期推。
这类“衍生字段清洗”在画像和统计里特别常见。
14）筛异常值
有些成绩字段、消费字段、学分字段，可能出现明显不合理的数据。
更稳妥的做法通常不是直接改，而是先筛出来。
如果确实要兜底：
⚠️ 异常值是否要截断，必须先问清业务规则，不能技术人员自己拍脑袋决定。
15）类别字段映射成统一口径
学历层次、会员等级、订单状态、部门类别，经常存在别名和历史写法。
如果映射规则很多，建议单独维护码表，不要把所有逻辑都硬写在 CASE WHEN 里。
16）多表关联前先清洗关联键
很多 JOIN 对不上，不是表没关系，而是关联键脏了。
经验上讲，JOIN 前先对学号、工号、身份证号做一轮 trim()，能少掉很多莫名其妙的问题。
17）识别缺失率
清洗前，先知道哪一列最脏。
这段很适合做字段质量画像。
18）统一布尔字段
很多系统里的“是否激活”“是否删除”“是否有效”字段特别乱。
统一成 0/1 后，后面的统计和建模都会省很多事。
19）拆分复合字段
有些源表喜欢把多个信息塞在一个字段里，比如“学院-专业-班级”或者“省份-城市-门店”。
这种字段不拆，后面几乎没法做严肃分析。
20）建一个清洗视图，别每次重写
很多人写 SQL 清洗最大的问题，不是不会写，而是每次都从头写一遍。
如果某张表是高频使用的，建议直接建一个清洗视图：
这样后面做报表、做标签、做专题分析时，直接查视图就行，不用每次重新洗。
最后说几句真经验
如果你平时就在做数据分析、报表开发或数据治理，我的建议就四句：
第一，别一上来就想着“把所有问题一次洗干净”。
先抓高频字段：主键、姓名、手机号、日期、状态、编码、类别。把这些核心字段洗顺了，后面大部分分析就能跑起来。
第二，能用码表解决的，不要全写死在 CASE WHEN 里。
规则一多，SQL 会越来越难维护。
第三，异常值先查再改。
很多时候你以为是脏数据，其实是业务规则特殊。
第四，清洗不是一次性动作。
更理想的做法不是“分析前临时洗一次”，而是把高频规则沉淀成视图、宽表、清洗层，慢慢变成稳定的数据底座。
说到底，SQL 数据清洗没有什么玄学。
你真正需要的，不是 200 个冷门函数，而是把高频脏问题反复收敛的能力。
如果这篇对你有帮助，建议先收藏。
后面真遇到脏数据时，再回来按场景翻就行。
你平时最常碰到的数据清洗问题是哪一种？
空值、重复值、日期格式混乱，还是多表 JOIN 对不上？