BK-CI 数据库设计 适用场景 - 新增或调整表结构 - 编写 DDL、DML 或增量更新脚本 - 设计索引、唯一约束、查询路径 - 评估是否需要分表、归档或冷热分层 - 审查某个数据模型是否适合当前服务边界 不适用场景 - 只是写一条临时查询 SQL 排查数据 - 只是改业务代码，不涉及持久化模型和表结构 - 需求本质是 API 设计、模块归属或权限模型，不是数据库设计 快速指导 1. 先确认数据归属到哪个服务。BK-CI 采用微服务拆分，禁止因为方便查询而跨服务共用数据库。 2. 先决定表的角色，再决定字段和索引： - 主实体表：存核心业务状态 - 关系表：表达多对多或映射关系 - 汇总表：承载聚合读模型 - 历史表：承载高频追加或归档数据 3. 先按查询路径设计索引，不要先堆字段。最常用查询条件、排序字段、唯一约束字段优先进入索引设计。 4. DDL 变更必须走脚本管理，不要直接在数据库里手工改线上结构。 5. 变更前先考虑兼容性： - 老字段是否仍被旧版本代码读取 - 新字段是否需要默认值 - 是否需要分阶段发布 6. 大表问题优先判断是索引、归档、冷热分层还是分表，不要默认直接分片。 7. 对 JSON、大文本、状态快照类字段，要明确为什么不能拆表，避免把主表做成“万能存储”。 高信号规则 - 脚本命名和版本目录要保持统一，详细规则见 - 分表与路由策略的细节见 -…