号码数据库系统怎么设计才不会越用越乱

一套 号码数据库系统 用三个月后脏掉，很少是因为 PostgreSQL 不行。更常见的是：unique 建在原字符串上、没有来源批次、改了规则却不记版本、所有人都能导出全库。库一乱，去重结果就开始无法解释。

业务侧怎么用库，见 自建号码数据库怎么落地。下面写表怎么拆、哪些字段不能省。制作顺序见 自建号码数据库系统怎么做。

权威数据是键，不是用户看见的那一格

最少两张逻辑表（可以物理合成一张，但概念上要分开）：

号码实体（按键唯一）

• key：规范化后的唯一键，通常 E.164
• region
• first_seen_at / last_seen_at
• status：有效、投诉、测试、观察（观察号不要当重复依据，除非业务明确要求）

出现记录（每次导入一行）

• 关联到 key（异常行可以没有 key）
• raw
• batch_id / source
• task_id
• rule_version
• result：通过、文件内重复、历史重复、异常
• reason_code

只保留实体、不留出现记录，你将无法回答“这批名单里哪些撞了库”。只留出现记录、实体不 unique，库会在重复采购包之后迅速膨胀。

来源批次不是备注，是回滚开关

source=2026Q3-渠道A 这种标记要能支撑：

• 按批撤回（地区设错、测试数据进了生产）
• 重复结果里展示“命中了哪类历史”，而不展示整库
• 渠道质量统计（某包文件内重复率异常高）

没有 batch_id，撤回只能按时间删，容易误伤同时导入的其它包。任务和批次的关系，见 手机号码批量去重任务设计。

规则版本要跟每一行结果在一起

地区元数据会更新，号长判断会改。改完如果直接覆盖旧键：

• 旧任务无法复盘
• 同一原值新旧键并存，去重率假性下降
• 探针号对不上

所以结果行记下 rule_version。规则升级后提供重算，而不是在原地偷偷 parse 出另一种 key。全球规则怎么做，见 全球号码去重系统。

索引为“在不在”服务，不为模糊搜索服务

去重查询是精确命中 key。索引就应该是 key 的 unique（或等价结构）。不要指望：

• 对 raw 做模糊搜来“智能去重”
• 在 SQL 里每次 replace(replace(raw...)) 再比

后者在十万行还能忍，到百万就是全表计算。快速路径的瓶颈分析见 号码快速去重软件为什么慢。

分区可以按地区或按 key 哈希，那是量上来以后的事。第一版先保证键窄、写入批量、查询不被大导入堵住。

权限是库设计的一部分

号码数据库系统如果任何人 SELECT * 再另存 xlsx，自建的安全意义就没了。设计时就要假定：

• 业务账号不能扫全表
• 导出接口按任务出结果，不按实体表出全量
• 管理员导出全库走审计

这不是后期加个角色开关那么简单，有时意味着根本不提供“浏览全部号码”的页面。协作场景见 号码去重复软件如何多人查重。

几个不该放进号码库的东西

• 空号、停机、在网状态：外部数据，时效短，和“是不是同一号”分开存
• 客户姓名合并、一人多号：那是 CRM，硬塞进来会把 unique 搞乱
• 明文可下载的全量备份丢在业务桌面：备份是运维通道，不是功能

去重和清洗的边界见 号码去重和号码清洗的区别。

设计时可以先写的检查项

上线前对着库问这四个问题：

1. 同一号的五种写法，实体表里是不是一行？
2. 错导入的一批，能不能按 batch 撤干净？
3. 半年前某次任务的结果，还能按当时规则解释吗？
4. 销售角色能不能把全库带走？

四个里有一个答不上来，库会在业务一忙时开始乱。产品侧对应能力见 核心功能，存储和并发见 底层架构。

常见问题

必须用关系型数据库吗？

权威数据和出现记录需要能查询、能撤回、能审计。关系型很合适。Redis、内存集合可以做热路径，不建议当唯一底库。

测试号、员工号怎么放？

单独 status 或单独 source，默认不参与“历史重复”拦截，除非你明确要拦。混进正式客户实体又没有标记，后面只能靠人认。

想先看库和任务长什么样再定表？

打开 在线 Demo 看导入、状态和导出字段。按自己的底库部署，联系 Telegram @imchat。