跨境团队一上手，很容易按业务线拆库：英国包进英国库，东南亚包进东南亚库，国内号再单独一张表。三个月后要做一次“全球去重”，就得把几套字符串再洗一遍。 全球号码数据库系统 的目标是反过来：号码只在一套库里，地区是任务参数，键全局唯一。
单库的表怎么设计，见 号码数据库系统怎么设计。国家码在名单里怎么乱，见 全球号码批量去重。
按国家拆库，看起来清晰，对账时最痛
拆库的好处是权限好像更好切、索引好像更小。实际会被这几件事打脸：
- 同一份渠道包里混了多个国家，运营不知道该导进哪套
- 号码没带国家码，进错库之后键按错误地区生成
- 同一人用英国号和泰国号是两件事，但同一泰国号写成
+66和0开头会被送进不同库 - “这人是不是全球都不要再触达”变成多次查询、多次导出再人工合并
跨境营销里重复触达特别贵，原因见 跨境营销名单去重。多套库会把“查一次”变成“查 N 次还可能漏”。
一套全球号码数据库系统最少要有的四层
概念上只需要：
- 地区元数据：国家码、号长、trunk prefix、规则版本
- 号码实体：按规范化键 unique，记下 first_seen / last_seen / 状态
- 出现记录：每次导入的 raw、batch、任务、结果
- 任务：默认地区、操作人、文件、导出产物
查询“在不在”只打键。不要对 raw 做模糊搜，也不要按国家把实体表物理拆成互不相通的多套 unique。量上来再按键哈希或地区分区，那是存储策略，不是业务上的“多套库”。
默认地区在任务上，不在库名上
全球号码数据库系统里，最危险的常量是 DEFAULT_REGION=CN 写死在配置文件。同一天下午要跑英国包和越南包，库名却叫 db_cn，没有人会记得改。
正确的是：
- 库是全球的
- 每个任务必须选默认地区
- 号码已带
+/00时，以号码自带地区为准 - 没带又没选地区的行进异常，不要猜
格式引擎的顺序见 全球号码去重系统开发。猜对了的行会进 unique，错键比漏处理更难挖。
权限按角色切，不按“给你一个国家库”
拆库常被当成权限方案：英国团队只能碰英国库。更干净的做法是：
- 同一套实体表
- 运营只能下载自己任务的结果
- 按来源批次授权“某渠道包”而不是“某国家整库”
- 管理员整库导出走审计
业务账号下不到全量，就不需要靠物理拆库来防泄漏。协作方式见 号码去重复软件如何支持多人查重。
什么时候才值得分区，而不是新建一套库
可以分区或分片的信号：
- 单表已经到必须按键哈希才能稳住写入
- 单条查询被大导入堵住，需要读写隔离
- 合规要求某地区数据物理落在某区域（这是合规分区，仍应对外呈现一套系统）
不是信号的：
- 新开一个出海国家
- 某个销售团队只要看自己的包
- 想让索引“看起来小一点”
新国家应该加元数据和规则版本，而不是新克隆一套库。维护期怎么扩地区，见 全球号码数据库系统上线后怎么维护。
常见问题
已经拆成多套了，要不要立刻合并？
先冻结规则，把各库的键按同一套元数据重算，用探针号对账，再迁到一套全球号码数据库系统。不要把几份 raw 直接 union。
全球库会不会让国内号变慢？
键短且有 unique 时，国家数量不是查询瓶颈。变慢通常来自对 raw 现场规范化、单条 insert，或导入和查询抢同一条写路径。
想先看一套库里多地区任务长什么样？
在线 Demo 上传不同默认地区的样本。按全球底库部署，联系 Telegram @imchat。