UI 列空白 ≠ 字段为 NULL：悬挂外键引用才是真凶

运营反馈某后台管理系统的列表页，"所属门店"这一列有几百条记录显示为空白，要求把这些"脏数据"软删掉。听起来很直白的清理需求，结果第一个 SQL 就把人整蒙了。

现象

用户说：「这些记录没有关联门店，帮我把它们 del_flag 设成 1 清掉。」

写下最直觉的查询：

SELECT COUNT(*) FROM user_role_binding
WHERE store_id IS NULL OR store_id = '';

结果：0 行。

翻遍数据，store_id 列确实全都有值，不存在任何 NULL 或空字符串。但前端列表"门店名"这一列确实大量空白，肉眼可见几百条。

根因

后端 Service 层并没有用 SQL LEFT JOIN 来组装门店名，而是典型的 in-memory join 模式：先查出主列表，再一次性把所有"启用状态"的门店捞进一个 Map，然后 for-each 遍历列表往里塞名字。

// Service 伪代码
List<UserRoleBinding> list = mapper.selectList(qw);
 
Map<String, Store> storeMap = storeMapper
    .selectList(new QueryWrapper<Store>()
        .eq("del_flag", "0")
        .eq("status", "1"))   // 只加载"有效"的门店
    .stream()
    .collect(toMap(Store::getId, Function.identity()));
 
for (UserRoleBinding item : list) {
    Store s = storeMap.get(item.getStoreId()); // s 可能为 null
    item.setStoreInfo(s);   // null 直接塞进去，前端拿到就是空
}

关键在于：门店被停用（status=2）或软删（del_flag=1）后，user_role_binding 表里的 store_id 不会联动清理。storeMap 里根本没有这条门店，get() 返回 null，前端就展示空白。

坑：UI 空白 ≠ FK 字段为 NULL

WHERE store_id IS NULL 永远查不到这批"空白"记录，因为 store_id 有值，只是它指向的门店已经失效了。这是悬挂外键引用（dangling FK reference），不是字段缺失。

用 IS NULL 过滤后去批量 UPDATE，轻则无效，重则误伤真正的脏数据。

正解

第一步：先用 LEFT JOIN 还原 UI 真实条件

-- 数一下"UI 看不到门店名"的真实行数
SELECT COUNT(*)
FROM user_role_binding urb
LEFT JOIN store s
  ON s.id = urb.store_id
 AND s.del_flag = '0'
 AND s.status = '1'        -- 与 Service 过滤条件保持一致
WHERE urb.enable = '1'
  AND urb.store_id IS NOT NULL
  AND s.id IS NULL;        -- join 失败 = 门店已失效

或者反向 INNER JOIN 看是什么原因导致失效：

SELECT urb.id, urb.store_id, s.del_flag, s.status
FROM user_role_binding urb
INNER JOIN store s ON s.id = urb.store_id
WHERE urb.enable = '1'
  AND (s.del_flag = '1' OR s.status != '1');

第二步：定位引用表自身的"隐藏"字段

引用表本身不一定有 del_flag——很多表用 enable、status、is_active 之类的字段。DESC 一下表结构，找 Service 查询时用来过滤的字段，复用它而不是新加列。

第三步：事务 + 校验再执行

-- 先备份 ID 列表
SELECT id FROM user_role_binding ... INTO OUTFILE '/tmp/backup_ids.tsv';
 
BEGIN;
UPDATE user_role_binding SET enable = '2'
WHERE id IN (...);
-- 对比 affected rows 与预期 SELECT count，不一致先 ROLLBACK
COMMIT;

执行后再跑一次 LEFT JOIN 统计，应返回 0；刷新前端列表，原来的空行消失（前提：列表 API 硬过滤了 enable='1'）。

正解：LEFT JOIN 主数据 + 过滤失效状态

还原 UI 空白的 SQL 条件 = LEFT JOIN 主数据表 ON ... AND del_flag='0' AND status='1' WHERE s.id IS NULL，而不是 WHERE fk IS NULL。清理时复用引用表已有的业务软删字段，不要新加 del_flag 列。

排查时的三个触发信号

用户说"很多记录没有 X"，但 WHERE x_id IS NULL 返回 0
后端 Service 层有 in-memory join（fetch 列表 → 从 Map 取名字塞回去），而不是 SQL JOIN
主数据表有 del_flag / status / enable 生命周期字段，且主数据删除时不联动清理引用表

三条命中任意一条，就该换成 LEFT JOIN 模式来定位真实数量，再做清理。

一句话外卖

UI 列空白的 SQL 条件是「FK 指向了失效主数据」，不是「FK 为 NULL」——先用 LEFT JOIN + 主数据生命周期字段还原真实条件，再动 UPDATE。