我第一次被数据质量整到头皮发麻，是在接手一套跑了两年多的YashanDB业务库之后。月末报表怎么都对不上总账，查了一圈才发现资金流水表里混进了几十条金额字段为NULL的记录；订单表里同一个客户ID下存在三条完全一样的下单记录，业务系统却毫无感知。那一刻我认识到一个再简单的道理：数据库选型再好、性能再高，如果里面的数据是脏的，一切都会跟着跑偏。
YashanDB作为国产企业级数据库，这些年越来越多地出现在核心交易、政务、金融等场景里，它的SQL兼容性、分布式能力和高可用设计都没得说。但数据质量这事，数据库本身只能提供工具，真正决定质量的还是建表规范、写入逻辑、清洗策略和持续治理。这篇文章我会分享一套我自己在YashanDB环境里实际验证过的方法论，一共五个方向，覆盖约束设计、格式标准化、存量清洗、重复识别和监控闭环，适合正在被脏数据折磨的DBA、数据开发以及需要直面业务表的后端工程师参考。
1. 数据质量失控的根源：脏数据从哪来，代价有多大
1.1 我在YashanDB线上库里见到的几类典型脏数据
很多人以为脏数据就是"字段是空的"或者"格式不对"，实际接触下来，问题远不止这么简单。我在维护YashanDB实例时归纳过，线上出现的数据质量缺陷基本可以划成五类：
| 质量维度 | 典型表现 | 常见来源 |
|---|---|---|
| 完整性 | 关键字段为NULL，如订单金额、客户身份证号 | 应用层漏传、接口中断、人工补录不规范 |
| 唯一性 | 同一业务实体出现多条重复记录 | 并发提交、幂等缺失、多系统重复同步 |
| 一致性 | 同一条数据在不同表中口径不一致 | 多套上游系统各自维护、同步规则混乱 |
| 准确性 | 数值越界、逻辑矛盾，如负数的库存、子单金额大于主单 | 校验缺失、手工改数、下游计算污染上游 |
| 时效性 | 数据长期不更新、状态停滞 | 同步任务失败后未告警、数据接口断开 |
这里面最坑的是"口径不一致"。比如客户表里手机号有的存11位，有的存了带区号的格式；性别字段有的是"1/0"，有的是"男/女"，还有的是"M/F"。当你写统计SQL时，每种写法都能查出不同的结果，对账对不上往往就是这类问题叠加出来的。
1.2 数据质量差的代价远不止报表难看
数据质量差的第一个代价是统计报表失真。领导看报表，差一分钱都会追问，而脏数据导致的口径漂移很难解释清楚。第二个代价是业务处理异常，重复订单导致多发货、负数库存导致负卖，这些都是真金白银的损失。第三个代价是系统之间对账失败，YashanDB里主数据还算干净，但同步到数据仓库或周边系统后，因为字段标准不一致导致整天有人来问"为什么两边对不上"。
更深层的问题是运维成本。当你不知道哪个数据是可信的，每次排查问题都要把整条链路重新捋一遍，一个简单的数据问题可能拖上半天。所以数据质量治理不是锦上添花，它是数据库稳定运行、业务有序推进的地基。
2. 方法一：前置拦截——用约束、默认值与触发器把脏数据挡在门外
2.1 约束设计：一张业务表至少要配齐哪几把"锁"
我最推荐的做法，是在数据还没进表之前就把规则定死。YashanDB的SQL体系兼容主流关系型数据库语法，建表时加上约束几乎是零成本的事，但很多人因为图省事或怕影响性能，把约束全省了，结果脏数据长驱直入。
以一张最简单的订单表为例，下面这些约束应该一个都不能少：
CREATE TABLE t_order ( order_id NUMBER(20) NOT NULL, customer_id NUMBER(20) NOT NULL, order_amount NUMBER(14,2) NOT NULL, order_status VARCHAR2(20) NOT NULL, order_time DATE NOT NULL, channel_code VARCHAR2(10), CONSTRAINT pk_order PRIMARY KEY (order_id), CONSTRAINT chk_order_amount CHECK (order_amount >= 0), CONSTRAINT chk_order_status CHECK (order_status IN ('待支付','已支付','已发货','已完成','已取消')) );- NOT NULL保证完整性，做统计时不至于被NULL值带偏；
- 主键保证唯一性，从物理层面杜绝完全重复的订单ID；
- CHECK约束保证准确性，金额小于0的订单根本插不进表；
- 枚举类CHECK保证一致性，状态只允许这几个合法值。
外键约束同样重要。如果子表引用了主表不存在的客户ID，这种"孤儿数据"就是典型的一致性缺陷。虽然外键在超高并发下有一定代价，但在核心业务表上，该加还是要加，它挡住的是一整类数据问题。
提示：不要用"应用层已经校验过了"当理由省掉数据库约束。应用层校验只对走这个应用的请求有效，而后台直改、数据同步、手工导入这些路径都可能绕过应用层，只有数据库约束才是最后一道谁都绕不开的关卡。
2.2 默认值与触发器：处理漏传字段和隐含规则
约束能拦住非法数据，但很多字段不是"非法"，而是"该有却没人填"。比如创建时间、最后更新时间、初次来源渠道这些字段，应用层偶尔会漏传，设一个合理的DEFAULT值是成本最低的兜底方案。
CREATE TABLE t_customer ( customer_id NUMBER(20) NOT NULL, created_time DATE DEFAULT SYSDATE NOT NULL, source_channel VARCHAR2(20) DEFAULT 'UNKNOWN' NOT NULL );YashanDB兼容模式里DEFAULT SYSDATE可以自动填充时间，source_channel给一个"UNKNOWN"而不是NULL，后续排查数据来源时就不会出现"怎么查不到渠道"的情况。
触发器适合处理更复杂的写入规则。比如要求金额大的订单必须记录审批标记，或者在删除主数据前自动检查是否存在关联子表。但触发器要克制地用，尤其是高频写入表上，滥用触发器会把写入链路搞得很重，甚至拖慢并发。我的原则是：能靠DEFAULT和CHECK解决的不用触发器，触发器只解决"多字段联动的写入逻辑"。
2.3 给存量表加约束的踩坑经历：别在大流量时段硬来
理论很美好，现实是很多表已经跑了好几年，想在存量表上加约束时往往会遇到一个尴尬局面：数据本身已经不干净了，加NOT NULL报错，加UNIQUE报错。这时候不能硬加，得先清洗再加固。
另外，给大表加约束时要注意锁的影响。我在一个订单流水表上加CHECK约束时赶上业务高峰期，DDL一直等不到锁，后续写入全部堵住，差点引发线上故障。后来学乖了：先评估表的数据量和写入活跃度，尽量在业务低峰期操作；YashanDB也会自动处理DDL锁的调度，但仍建议在变更窗口执行，并且分批验证约束的可行性，先写出"违规数据查询SQL"确认查不到明细，再加约束，这样加约束的成功率会高很多，也不会把并发扛压的库拖进死锁泥潭。
3. 方法二：格式与口径标准化——让"看似一样"的数据真正一样
3.1 字符集与编码：乱码不是玄学，是规则没对齐
多套系统往YashanDB同步数据时，最容易踩的第一坑就是字符集。源端是GBK，目标端是UTF8，同步过程中如果没做转换，中文会出现乱码；更隐蔽的是"看起来一样但实际字节不一样"的半角全角问题，比如手机号里的全角数字"１３８"和半角"138"，肉眼无法分辨，但SQL比较时就是不一样。
我的建议是接入数据前先做编码探测，制定统一规则：所有字符数据在YashanDB里一律使用UTF8编码，同步任务里统一做编码转换；对于全角半角、大小写、首尾空格等细节，在接入层用标准化函数处理一遍。实践中可以用TRIM、UPPER和正则替换把文本先洗一遍：
UPDATE t_customer SET mobile = REGEXP_REPLACE(TRIM(mobile), '[[:space:]]', '') WHERE mobile IS NOT NULL;这条SQL会把手机号里的首尾空格和中间不可见字符清掉。别小看这种操作，我排查过好几次"数据明明一样但关联不上"的问题，最后发现都是不可见字符惹的祸。
3.2 日期、时间、数字、空值的统一规范
日期字段是格式问题的重灾区。同一个业务系统里，有人传"2025-06-01 10:30:00"，有人传"2025/06/01"，还有人存的是字符串"20250601"。在没有统一规范之前，排序、区间查询全部可能出错。
在YashanDB里，我最常用的标准化手段是TO_DATE和TO_CHAR显式转换，杜绝隐式依赖：
SELECT TO_CHAR(TO_DATE('2025/06/01', 'YYYY/MM/DD'), 'YYYY-MM-DD') AS std_date FROM dual;给业务定的规矩很简单：日期时间一律存DATE/TIMESTAMP类型，不存字符串；代码里所有日期比较都用TO_DATE转成日期类型再比较；应用层传入的日期格式统一为'YYYY-MM-DD HH24:MI:SS'。
空值的规范同样重要。我见过一张表中NULL、'NULL'字符串、空字符串''三种"空"同时存在，查询时每个都写一种条件，漏一个就出错。规范就是：没有值的字段一律存SQL的NULL，不允许写空字符串占位，更不允许把"NULL"当字符串写入。
3.3 用字典表和值域映射统一业务口径
第三种标准化是在元数据层面建字典表。比如性别，与其让各系统传"1/0""男/女""M/F"，不如统一存字典编码，展示层再去翻译。我在项目里通常建一张t_dict表和一张t_dict_mapping表，把业务字段与合法取值对应起来，CHECK约束可以直接引用字典编码，后续新增取值时只需要改字典表，不需要改代码和表结构。
这样做还有一个额外好处：跨系统同步时，以字典表为唯一标准，任何来源的数据入库前先做一轮映射转换，不一致的口径在源头就被消除，后面写统计SQL时再也不用担心"这个系统传的1到底是不是另一个系统传的男"。
4. 方法三：SQL驱动的存量清洗——合规搞定历史脏数据
4.1 清洗前先做数据体检：写诊断SQL，不凭感觉动手
约束和标准化只管住新写入的数据，历史存量数据还是要靠清洗来解决。清洗的第一步不是动手改数，而是先做诊断。我在YashanDB里最常用的几类诊断SQL长这样：
查询缺失关键字段的记录数：
SELECT COUNT(*) FROM t_order WHERE order_amount IS NULL;查询重复记录：
SELECT customer_id, order_no, COUNT(*) FROM t_order GROUP BY customer_id, order_no HAVING COUNT(*) > 1;查询越界数据：
SELECT COUNT(*) FROM t_order WHERE order_amount < 0 OR order_time > SYSDATE;诊断的原则是"每条规则对应一条SQL，每个结果都留下截图或者落表记录"。这样清洗前就有了一份"问题清单"，既能用来评估工作量，也方便清洗后对照验证。我强烈建议把诊断SQL沉淀成一个质量检核脚本库，以后每次大版本升级、数据迁移之后都能复用。
4.2 清洗SQL实战：NULL填充、格式规整、条件UPDATE
诊断完就可以动手。最常见的清洗场景有三个：
- 对可推导的NULL值进行回填。比如渠道字段为NULL，但日志表里有该客户的下单渠道，可以通过关联UPDATE补上。回填前务必备份或记录影响行数。
- 对格式混乱的字段做统一转换。把字符串日期转成DATE类型，把全角数字统一为半角，把英文枚举值翻译成字典编码。
- 对越界数据做修正或打标。金额为负的根据业务规则判断是调整为正数还是标记为异常；无法判断的，宁可先置为业务认可的默认值并记入异常清单，也不要直接删。
做UPDATE清洗时，我一直强调"小步快跑"——不要一次性UPDATE全表几百万行，尤其不要写一条不带充分条件的UPDATE。可以按ID区间或按时间批次处理，每批次控制在几千行以内，观察执行计划和影响行数，确认无误再跑下一批。这样即使某批出错，影响面也可控。
4.3 事务与备份：清洗操作必须可回滚
清洗是动真数据，风险不亚于线上发布。我用YashanDB时养成了一套保命习惯：
- 清洗前先做逻辑备份，或者把待清洗的主键和原始字段导出到一张备份表；
- 用事务包裹清洗SQL，先在事务里执行并查询验证，确认结果正确后再COMMIT；
- 每批次清洗后统计影响行数，并与诊断SQL的问题清单比对，看看是否完全覆盖；
- 清洗完成后重新跑诊断SQL，确认问题数量归零。
BEGIN UPDATE t_customer SET mobile = REGEXP_REPLACE(TRIM(mobile), '[[:space:]]', '') WHERE mobile IS NOT NULL; UPDATE t_order SET order_status = TRIM(order_status) WHERE order_status != TRIM(order_status); COMMIT; END;这套流程看起来繁琐，但能避免"清洗反而破坏数据"的事故。我见过有同事一条UPDATE把某个字段全表更新成同一个值，如果没备份，整个表就废了。可回滚是最低要求，别在这上面省时间。
5. 方法四：重复与相似数据识别——合并去重的正确姿势
5.1 精确去重：用窗口函数找出保留行，而不是随手DELETE
先处理最简单的精确重复——多行数据的每个字段都完全一样。很多人第一反应是GROUP BY + DELETE留下MIN(ID)，但这种做法有时候会误伤关联数据。更稳妥的方案是用ROW_NUMBER()窗口函数给重复行编号，先查出来哪些是要保留的行、哪些是候选删除行。
SELECT order_id, order_no, customer_id, ROW_NUMBER() OVER (PARTITION BY order_no ORDER BY order_id) AS rn FROM t_order;PARTITION BY order_no表示按订单号分组，对组内重复的记录按order_id排序编号，rn=1的作为保留行，rn>1的就是重复行。先把这份结果落到一张临时表，人工或半自动确认后，再按order_id列表删除。
之所以不建议直接DELETE，是因为你需要留给人眼确认的机会。自动删除的脚本一旦写错条件，删错数据是很难找回的，特别是核心交易表，宁可多查一次，不要少看一眼。
5.2 相似数据识别：编辑距离、归一化与多字段打分
精确去重只能解决完全一样的情况，现实里更常见的是"看似不同，实则同一条"。比如客户名称"深圳市科兴信息技术有限公司"和"深圳科兴信息公司"，姓名里的"张伟"和"张 伟"，这些在精确匹配下都不会被识别为重复，但业务上可能就是同一个人。
处理相似记录，我的经验是分三步：
- 字段归一化：去掉空格、统一大小写、把缩写展开成全称；
- 计算出相似度：借助编辑距离函数或自定义存储函数，给每条候选记录对比打分；
- 多字段交叉验证：单一字段容易误判，至少结合姓名+手机号、公司名+地址、身份证号+姓名等多组权重来综合判断。
如果YashanDB环境里没有现成的编辑距离函数，可以用UTL_MATCH.EDIT_DISTANCE这类兼容函数，或自己写一个PL/SQL函数来实现。重点不是算法多高级，而是在业务可以接受的误差率内产生一份"疑似重复清单"，交给业务方二次确认。清淤去重不可能100%自动化，机器负责缩小范围，人负责拍板。
5.3 去重不只是删行：关联数据合并与保留策略
很多人去重时只顾着删主表的重复行，忘了还有一堆子表引用着这些行的ID。如果父表删了某条记录，子表的外键还指向它，关联查询就全断了。
我处理带关联关系的去重时，流程通常是：先选定保留的主记录，然后把其他重复记录的关联业务归并到保留记录上，最后才在确认无引用后删掉冗余记录。YashanDB的外键约束在这里会发挥保护作用，如果直接删除有外键关联的父记录，数据库会拒绝执行或触发级联操作，这个报错其实是在提醒你别乱删。
保留策略也有讲究。不是ID最小就一定最好，要结合业务判断哪条记录是最完整的、最近更新的、来源最可信的。我在客户主数据合并时，就遇到过保留的那条恰好是信息缺失的那条，合并完反而更脏，后来改成"字段级取优"的合并策略——不同来源的字段各取最优值合并成一条新记录，整体质量才真正提升。
6. 方法五：监控指标与治理闭环——让数据质量可度量、可持续
6.1 定义你的数据质量指标：不要凭感觉说"数据还行"
一次性清洗做完不难，难的是防止新脏数据持续产生。我的经验是，先把"数据质量"从抽象概念拆成可量化的指标，再用人盯人的方式去巡检，质量就会慢慢稳定下来。常用的质量指标可以分成五类：
| 指标项 | 计算公式 | 合格基线（参考） |
|---|---|---|
| 完整性 | 1 - NULL数/字段总数 | 关键字段100%，非关键字段≥99% |
| 唯一性 | 重复记录数/总记录数 | 核心实体0重复 |
| 准确性 | 越界、矛盾记录数/总记录数 | ≤0.01% |
| 一致性 | 跨表单据不一致数/总记录数 | ≤0.01% |
| 时效性 | 超过N天未更新的记录数/总记录数 | 按业务定义 |
在YashanDB里，这些指标可以用视图固化下来，每天定时跑一遍，把结果写进一张数据质量日志表。时间一长，你手里就有了完整的质量趋势曲线，哪个表在哪段时间变脏了，都能看得出来。
6.2 用定时任务+质量检核SQL实现自动化巡检
手工跑SQL巡检不可持续，尤其是表多了以后。我在YashanDB上的做法是写一个质量巡检存储过程，里面按业务优先级逐表跑检核规则，每发现一类问题就插入一条质量日志。
CREATE OR REPLACE PROCEDURE sp_dq_daily_check AS v_null_cnt NUMBER; BEGIN SELECT COUNT(*) INTO v_null_cnt FROM t_order WHERE order_amount IS NULL; INSERT INTO t_dq_log(check_date, table_name, check_item, bad_count) VALUES (TRUNC(SYSDATE), 't_order', 'order_amount_null', v_null_cnt); COMMIT; END;然后通过JOB（如DBMS_SCHEDULER兼容的调度机制）每天凌晨自动执行。质量日志表里记录了每天的坏数据数量，超过基线的部分会触发告警。如果你对环境里的数据库同步工具、ETL任务比较熟，可以把同步任务失败导致的数据停滞也纳入巡检范围，比如检查"来源系统昨日有数据，目标表今日却没有新增"这类时效性异常。
提示：巡检存储过程要控制好资源消耗，不要在业务高峰执行。我习惯把巡检放在凌晨低峰期，且每个检核SQL只做COUNT或采样，不跑全量扫描，避免把生产库的I/O吃满。
6.3 从发现到修复的责任闭环：质量治理不是一次性运动
指标和巡检只是发现问题的手段，真正让数据质量持续提升的，是问题从发现到关闭的闭环机制。我的团队约定了一套简单规则：质量巡检发现的问题自动生成清单，指派给对应表的所有者；修复完成后更新处理状态，写明原因和修复SQL；月底统计一次各类问题的复发率。
这套机制看起来不复杂，但长期坚持下来效果很明显。以前脏数据是"出了事才处理"，现在变成了"每天自动体检、按单修复"。对DBA来说，最直观的好处是：半夜再也不会被业务方的"数据怎么又对不上了"的求助电话吵醒，因为告警和修复已经前置到了问题发生之前。
7. 一次真实整改复盘：从对不上账到量化治理
7.1 场景背景
这套系统的背景是一套基于YashanDB的订单交易库，上游有3个业务系统持续同步数据，另有一些历史数据是从老库迁移过来的。迁移时为了赶进度，很多字段没有按规范校验；日常同步又偶尔出现过任务中断和重复执行。结果就是：订单表存在重复记录、金额字段存在NULL、客户手机号格式五花八门、状态字段几位数大小写混杂。当时业务方反馈的一个典型问题是"查上个月的成交订单数，三个系统跑出来三个数"。
7.2 五步落地过程
整个整改按上面五个方法依次落地，顺序很关键：
- 先做诊断基线：跑完整套检核SQL，输出问题清单，评估影响范围；
- 再定约束方案：和业务方确认每个字段的合法取值和必填规则，形成建表和约束改造方案；
- 接着清洗存量：按"备份-事务-分批"流程处理历史脏数据，重点处理空值和重复；
- 同步标准化口径：统一日期、编码、字典，并把标准固化到同步任务的转换逻辑里；
- 最后上监控：实现质量巡检存储过程和告警，并定义每张核心表的质量基线。
整个流程用了两周多，其中清洗和确认业务口径耗时最长，真正跑SQL的时间反而占比不大。这让我意识到，数据质量工程最难的部分不是技术，而是确认"什么才算对"。
7.3 结果与心得
整改完成后，三套系统跑同一统计SQL出来的数字完全一致了；重复订单清零；金额NULL字段归零。后续月度巡检中，核心表质量基线连续三个月保持在达标线以上。这中间也踩过一些坑，比如曾有一批清洗SQL在同一事务里批量更新了几万行，虽然结果没问题，但因为开始前没有先小范围验证，过程中提心吊胆，后来我始终坚持"先跑一万行，看执行计划，再看影响行数，最后全量执行"。
最后再说一个实际体会：数据质量不是一个一次性项目，它更像数据库日常运行的一部分。约束、标准化、清洗、去重、监控这五件事里，前两件是打地基，中间两件是还债，最后一件是防止再欠债。如果你手头的YashanDB库已经积累了一定规模的脏数据，别急着一下子全改，先把诊断SQL跑起来，把问题清单列出来，按影响面排优先级，一步一步来，数据质量是完全可以被管住的。
