数据库设计

先给结论：我的默认倾向是用 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 索引之后，这个选项从"忍一