飞翔的十号SLT 写入数据库 NULL 值，这个问题我这两年做 SAP HANA 数据迁移时被问过太多次。同步任务明明绿灯，日志干干净净，可一查目标表，某个关键字段整片是 NULL。做数据抽取、数据同步的同事碰到这种情况，第一反应往往是去翻 SLT 监控看有没有报错，结果任务状态全正常，数据就像“凭空消失”了一样。
这篇内容主要面向正在用 SLT 做 HANA 数据落地、又恰好被空值问题折磨的人。不管你之前是 DBA、数据工程师还是 SAP Basis 顾问，只要手里有一张同步后出现大量 NULL 的表，这篇就能给你一套完整的排查思路和可落地的处理办法。我会把常见根因、定位顺序、修复动作和我自己踩过的坑都摊开来写。
1. 先看清楚这条链路：NULL 是怎么“丢”出来的
1.1 现象描述：哪些情况让我第一时间怀疑 SLT 配置
SLT 写入 NULL 的现象有好几种长相。最常见的三种：
- 整列都是 NULL，但源表这一列明明有值，且不是全空。
- 只在某几行出现 NULL，几乎每次增量同步后都会多出几条。
- 初始同步时一切正常，跑了几轮增量后，老数据也被“刷”成了 NULL。
前两种情况比较容易定位，第三种最诡异，因为它意味着后台有进程在修改已落地的数据，而不是新插入数据时写入了空值。我接到过不少需求，用户说“SELECT 出来全是 NULL”，查到最后其实是同步配置里有人加了个转换规则，把整行数据重写了一遍，而转换逻辑里因为某个字段为空，结果把目标表主键之外的其他字段也置空了。
如果只看 SLT 任务状态，这类问题几乎不会亮红灯。SLT 的监控看的是“抽取是否成功”“传输是否有异常”，它不太会主动告诉你“你这条字段的语义被改掉了”。所以做排查前，别把任务状态当作数据质量的依据，它只能证明复制动作执行了，不能证明数据内容是对的。
1.2 数据流转路径与“丢数据”的三个位置
SLT 全称是 SAP Landscape Transformation，本质是一套基于数据库触发器和定时轮询的数据复制引擎。数据从源表进入到最终目标表，路径大致是：
code复制源表 → 源库触发器/日志表 → SLT 服务器抓取 → 目标 HANA 暂存/直接写入 → 目标表
只要理解了这条链路，你就能把“NULL 从哪来”拆成三个位置去判断：
- 源表本身就是 NULL，或者存的是“空字符串”，而空字符串在复制后被 DB 或表结构变成了 NULL。
- 在 SLT 的转换规则、字段映射、数据类型映射层被改写，原值被吞掉了。
- 写入目标表时因为精度、长度、非空约束等原因导致内容被丢弃，数据库层面默认落成了 NULL。
很多人一做 NULL 排查就直接翻目标表，这是第一步，但不能停在第一步。你要知道，源表、SLT 配置、目标 DB 是三层，每一层都可能产生或放大 NULL，定位时把链路拆开，效率立刻高很多。
1.3 绕不开的 SQL 三值逻辑：NULL 不是“等于空”
在做数据核对之前，必须要搞清楚一个基本概念：NULL 不等于空字符串，也不等于 0，更不等于“空格”。
在 SQL 的标准语义里，NULL 表示“未知”或“没有值”，它参与比较的时候结果是一个独立的真值 UNKNOWN，而不是 TRUE 或 FALSE。这就是常说的三值逻辑。如果你习惯了编程语言里的“if x == null”这种判断，非常容易在写数据库查询或转换逻辑时踩坑。
举一个非常常见的错误：
sql复制SELECT COUNT(*) FROM SLT_TARGET WHERE BUSINESS_PARTNER = '';
如果业务字段是 NULL，这一行不会被这条 SQL 统计到，因为 NULL 与空字符串比较的结果不是 TRUE，而是 UNKNOWN。很多人拿着这条 SQL 去统计“空值数量”，发现是 0，就误以为“没有空值问题”，实际表里 NULL 占比已经高得吓人了。
正确写法是显式判断：
sql复制SELECT COUNT(*) AS null_cnt
FROM SLT_TARGET
WHERE BUSINESS_PARTNER IS NULL;
SELECT COUNT(*) AS empty_str_cnt
FROM SLT_TARGET
WHERE BUSINESS_PARTNER = '';
两种统计要分开做。这就是为什么我在下面的排查步骤里，第一步永远是“先分清你面对的是 NULL 还是空串”，方向上差一个字，排查思路就完全不同。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。