标签频道
数据库设计
该标签下的文章、提问与讨论帖。
【背景】 做了 15 年数据库设计，我见过 90% 的业务表都带一个 is_deleted 或 deleted_at 列。理由通常很简单：「万一要恢复呢」「审计需要」「产品说不能真删」。上线时它确实是 5 分钟的事——加一列、改个 WHER
背景 我在一个 8 库 × 16 表的订单系统里做主键方案评审，业务方（运营 + 客服 + 审计）提了一个硬约束：订单号必须「肉眼可读」——能按时间排序、能看出分片归属（排障时直接路由）、能按业务前缀区分渠道（APP / H5 / 小程序）
【背景】 去年接手一张 5200 万行的订单主表（MySQL 8.0.36，InnoDB，16C64G 单机），接手时已经挂了 11 个二级索引。业务方最痛的一条慢查询：按「商户号 + 下单时间范围 + 状态」做分页查询，没走索引时 P99
【背景】 做了 5 年 DBA，日常被业务方问得最多的一句话是：「这条查询 P99 高，能不能加个索引把它打下来？」我的默认反应是先看 EXPLAIN 和写入路径，再决定动不动索引。但最近半年复盘慢查询工单时我发现，团队里两种做法各占一半，
【背景】 先说结论倾向：多数情况下，先重写查询、把物化视图当最后手段；但真正难的从来不是技术选型，而是缺少一个「可复用的判据」，最后都退化成架构师拍脑袋。 我最近处理的一条典型 case：一张 2.4 亿行的订单明细表（InnoDB，按 c
先给结论：我的默认倾向是用 varchar 存可读的枚举字符串，只有在「高基数、纯内部状态机、需要按值做范围/排序、且永不对外展示」的少数场景才退回 int。下面把这件事的分歧摊开聊聊。 【背景】 做了 10 年 DBA，表设计评审里被吵得
背景 做了 3 年 DBA，被开发问得最"理直气壮"的一类需求是："这个字段就为读方便一点，冗余到主表里吧，省得 JOIN。" 典型场景：订单主表 "t_order" 上挂着 "merchant_name"（商家名）、"status_tex
做了 8 年 DBA，慢查询治理几乎是日常。每次线上慢查询告警一响，我拉群拉人，第一句话经常被问的是"要不要加个索引"。但我越来越觉得，"加索引""改 SQL""改架构"这三条路各有各的适用边界，选错了代价不小。 我见过太多团队把"加索引"
背景 做了 5 年大数据平台，我在不同团队见过同一个问题被讨论至少五次：一张订单表，到底是把商品名、商家名、收货人、支付渠道全冗余进去（宽表），还是只存外键、查询时 JOIN 四张表（窄表）？ 两种做法我都深度参与过。宽表那张 1.2 亿行
背景 做了 5 年大数据平台，我见过太多团队在"要不要把半结构化数据塞进 JSON 字段"这件事上反复横跳。尤其是 MySQL 5.7+ 有了原生 JSON 类型、PostgreSQL 有 JSONB + GIN 索引之后，这个选项从"忍一
文
标题
摘要