业务侧已经认同要自己控数据之后，下一步卡在“机器买了，库还是空的，或者一倒进去就脏了”。 自建号码数据库搭建 不是把安装包点完就算完成，而是环境、权限和第一批底库按顺序就位，后面的每日比对才接得上。
“为什么要自建”见 跨境团队更适合自建号码数据库；系统功能和上线步骤见 自建号码数据库系统怎么做。这篇只谈搭建当天到第一周该准备的东西。
搭建前先冻结三句话，再申请服务器
很多团队第一天就装数据库。建议业务先书面确认：
- 哪些号必须进底库（成交、投诉、近两个季度获客包）
- 哪些号明确不进（测试号、员工号、来源不明的老包）
- 谁可以导出当次结果，谁可以导出整库
这三句不定，搭好的环境会变成“谁都能往里扔 Excel”。日常怎么用库，见 自建号码数据库怎么落地。
环境：先够用、可备份，再谈分布式
第一套自建号码数据库搭建，通常只需要：
- 一台可固定访问的应用节点（或容器）
- 一套可持久化的数据库，磁盘预留按“两年名单 + 索引”估，不要按当月文件估
- 对象存储或独立磁盘放原始上传文件（误判时要对照原单元格）
- 自动备份和恢复演练，备份通道不要对业务账号开放下载
云主机还是机房是运维选项。自建的含义是：规则、底库、账号在你控制的环境里，名单不必传到第三方在线工具。在线工具的安全边界见 在线去重工具能不能用。
第一版不要按“亿级”去买一排机器。库在百万级以内，规则和权限做错，加机器解决不了。
账号和网络和功能同一天开
搭建时同步做掉这些，不要“先能导入再说”：
- 管理员、运营、业务三套角色，业务默认不能扫全库
- 访问限制在公司网络或 VPN，演示地址不要当生产入口
- 操作日志：谁在何时导入、导出、改默认地区
- 测试库和生产库分开，测试用脱敏号
少了这几项，自建只是把泄漏面从网盘换成了自己的后台。
第一批底库：分层进，禁止五年 Excel 一日倒完
这是搭建阶段最容易翻车的一步。把历史所有采购包一次性灌进去，库会充满科学计数法破坏的号、未标地区的国际号、重复采购的同一包。unique 索引一旦吃进错键，后面只能人工挖。
建议第一批只进两层：
- 必须保护：成交客户、明确投诉、内部黑名单
- 近两个季度获客包：重复高发、来源还查得清
其余按周分批，带着 batch_id 和来源标记进。每一批导入后抽查：同一号的不同写法是否归一、探针号是否命中、异常行是否进了正式实体表。
一批发现默认地区设错，必须能按批次撤回。做不到撤回，就不要开下一批评次。
搭建完成的验收，不是“页面能打开”
环境搭完，用脏样本跑，不要用演示用的干净 11 位国内号。至少覆盖：
- 混写
+/00/ 本地号 - 英国或泰国带前导 0 的号
- 被 Excel 改成科学计数法的单元格
- 确定重复的探针号混在新文件里
通过标准：探针号被标历史重复、异常行不进实体、导出能重复下载、业务账号下不到整库。更完整的样本包见 号码数据去重软件怎么验收。
常见问题
自建号码数据库搭建一定要自己买服务器吗？
可以是云上的专属实例或客户 VPC。关键是数据和访问权在你这边，而不是把名单交给公共网页工具。
第一批底库要导入多少才算“建好了”？
以能挡住重复触达为准，不是以“库很大”为准。保护层齐、近季度包齐，就可以开始日常比对。历史老包慢慢洗。
想先看搭好之后任务和库的形态？
在线 Demo 看导入和导出。要在自己环境搭建正式库，联系 Telegram @imchat。部署形态见 底层架构。