推荐用自增整型作主键，因其写入快、索引紧凑、有序利于查询；避免UUID或字符串主键导致性能下降；字段类型应够用即止，索引需按高频查询条件设计，范式与反范式依业务权衡。
主键设计：为什么推荐用自增整型？
自增整型（INT UNSIGNED AUTO_INCREMENT）作为主键，是 MySQL 表设计中最常见也最稳妥的选择。它写入性能高、索引结构紧凑、B+树分裂少；同时天然有序，利于范围查询和分页。如果用 UUID 或字符串做主键，会导致聚簇索引频繁移动、插入变慢、磁盘占用翻倍，还可能引发锁竞争。
注意点：
- 业务上无强顺序要求时，也可考虑 雪花算法生成的长整型 ID，兼顾分布式与有序性
- 避免用复合字段（如 user_id + order_time）当主键，维护成本高且易出错
- 即使表有自然键（如身份证号），也不建议直接用作主键——不可变性难保证，且长度大、比较慢
字段类型选择：够用就行，宁小勿大
选对数据类型直接影响存储空间、查询效率和隐式转换风险。例如：tinyint(1) 常被误当作布尔用，但其实它只是 1 字节整数，语义应靠应用层或 CHECK 约束保障；varchar(255) 并非万能默认值，要按实际最长长度设，过大会浪费排序缓冲区（sort_buffer_size）。
实用建议：
- 状态类字段（如 status、type）优先用 TINYINT，配合注释或字典表说明含义
- 金额统一用 DECIMAL(10,2)，不用 FLOAT/DOUBLE，避免浮点精度误差
- 时间字段用 DATETIME（支持范围广、时区中立），而非 TIMESTAMP（自动更新、时区敏感、2038 年问题）
- 文本内容若确定 ≤ 500 字符，用 VARCHAR；超长或不定长用 TEXT，但避免在 SELECT * 中直接读取大字段
索引设计：不是越多越好，而是查得快、写得稳
索引本质是冗余的有序结构，加速查询的同时拖慢 INSERT/UPDATE/DELETE。关键原则是：**根据高频查询条件建索引，优先覆盖 WHERE、JOIN、ORDER BY、GROUP BY 涉及的列**。
常见误区与对策：
- 单表不建议超过 5–6 个索引，否则优化器可能选错执行计划
- 联合索引注意最左前缀匹配，比如 (a,b,c) 能命中
WHERE a=1、WHERE a=1 AND b>2，但无法用于WHERE b=2 - 区分“区分度高”和“过滤性强”：手机号比性别更唯一，但若查询频次极低，不如给高频低区分度字段加索引（如 is_deleted=0）
- 避免在低基数字段（如 sex、is_deleted）单独建索引，除非配合其他条件构成高频组合查询
范式与反范式：业务场景决定取舍
第三范式（3NF）能减少冗余、保证一致性，但过度规范化会带来大量 JOIN，影响查询性能。实际设计中常在 2NF 到 3NF 之间权衡，必要时局部反范式。
典型适用场景：
- 用户昵称、头像等基础信息，在订单表里冗余一份（非实时强一致），避免每次查订单都连用户表
- 统计类字段（如商品销量、评论数）单独维护汇总表或用触发器/应用层异步更新，不依赖实时 JOIN 计算
- 历史快照需求（如订单创建时的商品价格），必须保留当时值，不能只存外键引用最新商品表
- 日志类、流水类表可适当降范式，以写入吞吐为先，允许适度冗余
其他高频考点补充
面试中还常问到这些细节，需理解原理而非死记答案：
- NULL 的代价：每列 NULL 需额外 1 字节标记位；索引中 NULL 值不参与某些排序/去重逻辑（如 UNIQUE 索引允许多个 NULL）
- 字符集与排序规则：统一用 utf8mb4 + utf8mb4_0900_as_cs（MySQL 8.0+），兼容 emoji，大小写敏感按需选 _cs 或 _ci
-
软删除设计：用 is_deleted + deleted_at 组合，查询时务必加上
AND is_deleted = 0，否则索引失效；物理删除仍需定期归档清理 - 大字段处理：JSON 类型慎用——不易索引、解析开销大；高频查询字段尽量拆成独立列
