设计 MySQL 表结构时，很多团队只关注功能实现，忽略了数据模型对系统长期演进的影响。表结构设计没有绝对标准，但存在一系列经过实践检验的规范和建议。本文从字段类型、索引、范式与反范式、命名等维度，结合常见问题，给出可落地的判断依据和取舍原则。
字段类型选择：先定范围，再定精度
字段类型选择是表结构设计的基石。一个常见问题是：用户ID用 INT 还是 BIGINT？状态字段用 TINYINT 还是 ENUM？判断依据是数据量级和业务语义。
- 整数类型：INT 最大 21 亿左右，如果可能超过（如订单号、日志ID），直接使用 BIGINT。不要用 INT 存时间戳，语义不清晰且溢出风险高。
- 小数：金额、汇率等精确小数使用 DECIMAL，避免 FLOAT/DOUBLE 的精度误差。DECIMAL(10,2) 可满足大多数金额场景。
- 字符串：定长字符串（如 MD5、手机号）用 CHAR，变长用 VARCHAR。VARCHAR 长度按实际最大长度设置，不要盲目给 255，因为 MySQL 索引长度限制和内存排序会受影响。
- 日期时间：DATETIME 和 TIMESTAMP 的取舍。TIMESTAMP 范围到 2038 年，且有时区转换；DATETIME 更直观。建议使用 DATETIME，并统一存储 UTC 时间。
- ENUM：状态字段用 ENUM 可读性好，但扩展性差。如果状态可能增加，建议用 TINYINT 并注释说明。
索引设计：不是越多越好，而是按查询设计
索引设计是表结构规范的核心。很多开发者习惯为每个字段加索引，或者把索引建在低区分度字段上，导致写入变慢且索引失效。
判断索引是否合理的依据是查询模式。先列出所有高频查询的 WHERE、JOIN、ORDER BY 条件，再决定索引组合。常见规范：
- 为 WHERE 条件中的字段建立索引，但区分度低的字段（如性别）单独建索引效果差，适合联合索引前缀。
- 联合索引遵循最左前缀原则，例如 (a, b, c) 可以支持 a、a,b、a,b,c 的查询，但无法直接支持 b 或 c 条件。
- 使用覆盖索引减少回表，即在索引中包含 SELECT 需要的所有字段，例如 (user_id, status) 覆盖查询 user_id 和 status。
- 避免对索引列使用函数或隐式类型转换，否则索引失效。例如 WHERE phone = 13800138000 若 phone 是 VARCHAR，则查询会全表扫描。
一个常见误区是过度索引。每个索引都会增加写入和存储成本，且优化器可能选错索引。建议通过 EXPLAIN 分析执行计划，并定期用 pt-duplicate-key-checker 排查冗余索引。
范式与反范式：平衡数据一致性、查询性能与维护成本
数据库设计规范中，范式是理论基础，但实践中常需要反范式化。第三范式（3NF）要求消除传递依赖，但过度规范化会导致 JOIN 过多，影响查询性能。
一个典型场景：订单表需要冗余商品名称，还是通过商品ID关联？如果商品名称会变，且历史订单需要保留当时名称，则冗余是合理的。反之，如果名称变化不影响业务，则关联更符合范式。
判断依据是数据一致性与查询频率。对于高并发读场景，适当冗余（如统计字段、冗余名称）可减少 JOIN；对于强一致场景（如账户余额），应严格遵循范式，避免更新异常。
注意，反范式化会引入更新维护成本。例如冗余字段需要在业务代码中同步更新，或使用触发器（不推荐）。因此，反范式化前必须明确更新路径。
命名规范：统一风格，提高可读性
表名、字段名、索引名的命名直接影响团队协作和后期维护。没有统一规范时，常见问题包括大小写混用、缩写歧义、保留字冲突。
建议采用以下约定：
- 表名使用复数或单数均可，但全库统一。推荐使用业务模块前缀，如
user_account、order_info，避免无意义前缀如t_。 - 字段名使用小写加下划线，如
created_at，避免使用驼峰。 - 主键命名为
id，外键命名为业务_id，如user_id。 - 索引命名：主键
PRIMARY，唯一索引uk_字段名，普通索引idx_字段名，联合索引idx_字段1_字段2。 - 避免使用 MySQL 保留字，如
order、group，若必须使用需加反引号，但建议直接改名。
字符集与排序规则：避免乱码和排序异常
字符集选择是表结构设计容易忽略的环节。如果业务涉及中文，推荐使用 utf8mb4，它支持完整的 Unicode，包括 emoji。旧的 utf8（utf8mb3）不支持 4 字节字符，可能导致数据丢失。
排序规则（collation）影响比较和排序。默认的 utf8mb4_general_ci 性能较好但不区分大小写，utf8mb4_unicode_ci 更准确。如果业务要求大小写敏感，需使用 _bin 后缀的排序规则，或在查询时使用 BINARY 关键字。
注意，库、表、字段的字符集可以不同，但建议全库统一，避免 JOIN 时隐式转换导致索引失效。
主键设计：自增还是业务主键？
主键设计直接影响 InnoDB 的索引结构。InnoDB 是聚簇索引，数据行按主键顺序存储，因此主键的选择对插入性能影响很大。
自增整数主键是最常见的选择，因为插入顺序与索引顺序一致，减少页分裂。但如果表是分库分表，全局唯一ID需用雪花算法等方案，此时主键是 BIGINT 且非自增，插入随机，可能造成页分裂，但可通过调整 innodb_autoinc_lock_mode 和预分配优化。
业务主键（如身份证号）通常不推荐，因为业务字段可能变更，且长度较长，导致索引空间大。如果必须使用，需确保唯一且稳定。
设计规范中的常见误区与失败条件
即使遵循上述规范，也可能陷入误区。以下列举典型失败条件：
- 过度设计：为未来可能的功能预留字段，导致表宽泛且利用率低。建议按需设计，后续通过 ALTER 添加。
- 忽略 NULL 值：允许 NULL 的字段在查询时容易忽略索引，且统计函数（COUNT）行为不同。建议尽量 NOT NULL，并用默认值（如 0、空字符串）替代。
- 不设置外键：虽然 MySQL 支持外键，但高并发下外键会影响写入性能，且维护成本高。很多团队在应用层保证一致性，但需明确取舍。
- 忽略行大小限制：InnoDB 单行最大约 65535 字节，若 TEXT/BLOB 过多可能导致行溢出，影响性能。建议将大字段拆分到关联表。
参考资料
延伸阅读