表结构设计中怎样避免慢

在数据库表结构设计中，“避免慢”主要是指在数据量增长、并发增加时，仍能保持查询、写入、更新高效，防止出现慢查询、锁等待、全表扫描等问题。

下面从表结构设计层面（不是单纯加索引）系统讲怎么避免慢。

一、避免“宽表 / 大字段”拖慢性能

1. 控制列数量

• 列不要过多（一般 < 50 列较合理）
• 宽表会导致：
  • 行变大
  • 内存命中率下降
  • 一次 IO 读取更少行

2. 大字段单独拆表

不要在主表里放：

• TEXT / BLOB
• 长 JSON
• 文件内容

✅ 正确做法：

user(id, name, age)
user_profile(user_id, bio, avatar)

二、合理选择字段类型（非常关键）

1. 能用小类型就不用大类型

❌ 错误示例：

status VARCHAR(20)  -- 慢、占空间

✅ 正确：

status TINYINT

三、避免“隐式类型转换”导致索引失效

常见慢根因

WHERE phone = 13800000000
-- phone 是 VARCHAR

✅ 解决：

• 类型一致
• 或显式转换

四、避免“过度范式 / 过度反范式”

1. 过度范式（Join 太多）

• 10 张表 Join → 慢

2. 过度反范式（重复数据多）

• 更新成本高
• 数据不一致

✅ 建议：

• 核心表范式
• 统计/展示表反范式

五、设计“好索引的字段”

1. 索引字段要“干净”

❌ 不适合索引：

WHERE DATE(create_time) = '2024-01-01'

✅ 改成：

WHERE create_time >= '2024-01-01'
  AND create_time < '2024-01-02'

2. 避免低区分度字段做前导索引

❌：

INDEX(sex, user_id)

✅：

INDEX(user_id, sex)

六、避免热点行 / 热点表

问题场景

• 计数器在单行
• 订单表只有一个

解决方案

• 计数分片

counter_0 ~ counter_15

• 按用户 / 时间分表

七、时间类表一定要“可拆分”

设计原则

• 带时间字段
• 按时间分区或分表

✅ 示例：

order_202401
order_202402

八、主键设计影响巨大

1. 用有序主键

✅：

BIGINT AUTO_INCREMENT

或

雪花 ID

❌：

UUID（随机写，页分裂）

九、避免过度使用 NULL

• NULL 增加判断成本
• 索引效率略低

✅ 建议：

• 给默认值

status TINYINT NOT NULL DEFAULT 0

十、设计时就考虑“查询路径”

问自己：

这个表 80% 的查询是什么？

然后：

• 按查询建表
• 而不是按对象建表

总结一句话

表结构设计避免慢 = 小、窄、定、序、分

如果你愿意，可以：

• 发你的 具体表结构
• 或说明 慢查询场景

我可以直接帮你改表设计。