数据库设计是整个系统架构中影响最深远的一环。表结构一旦上线，随着数据量增长和业务迭代，改动成本会越来越高。很多项目后期出现的慢查询、数据冗余、字段含义混乱等问题，根源往往都可以追溯到最初的设计阶段。这篇文章将从范式、字段、索引、扩展性几个角度，把数据库设计的核心要点讲清楚。
为什么范式很重要，但不必死守
谈到数据库设计，绕不开三大范式。第一范式要求每个字段都是原子的，不可再拆分，比如联系方式不应该在一个字段里同时存手机号和邮箱；第二范式要求非主键字段完全依赖主键，不能只依赖联合主键的一部分；第三范式要求非主键字段之间不能相互依赖，比如表中已有部门编号，就不该再存部门名称。
范式化的好处很明显：数据冗余少，更新异常少，存储开销小。但范式化程度越高，表拆得越碎，业务查询往往需要关联多张表才能拿到完整数据。在互联网高并发场景下，多表关联是性能杀手，这时候适度反范式化反而是更好的选择。
实践中常见的做法是：设计初期严格按第三范式来梳理，保证结构清晰、职责单一；等真实查询需求明确后，再针对高频查询做冗余字段。例如订单表里冗余一份下单时的商品名称和单价快照，虽然违反了第三范式，但既避免了关联查询，也保留了历史时点的数据，一举两得。
字段与主键设计的细节
主键是每张表的骨架。推荐使用与业务无关的自增ID作为主键，InnoDB引擎下自增主键能保证顺序写入，避免页分裂，对性能友好。如果担心分布式场景下自增ID冲突，可以使用雪花算法生成分布式ID，但要注意它能保证趋势递增，不要用完全无序的UUID做主键，那会导致频繁的页分裂和巨大的索引开销。
字段类型的选择讲究够用就好。能用整型就不要用字符串，能用定长就不要用变长。比如状态字段用TINYINT就够了，用VARCHAR(50)就是浪费；定长且长度短的字符串如身份证号，用CHAR(18)比VARCHAR更合适。金额字段务必使用DECIMAL，浮点类型存在精度丢失问题，一旦涉及资金计算就会出事故。
另外几个容易忽视的点：所有字段尽量显式设置默认值，避免出现大量NULL，因为NULL会影响索引统计和查询条件判断；时间字段在MySQL 5.6之后推荐用DATETIME而非TIMESTAMP，前者范围更大且不受时区影响；每张表都应该有创建时间和更新时间字段，并利用数据库自动填充，方便排查数据问题。
CREATE TABLE `order` ( `id` BIGINT NOT NULL AUTO_INCREMENT COMMENT '自增主键', `order_no` VARCHAR(32) NOT NULL COMMENT '业务订单号，唯一索引', `user_id` BIGINT NOT NULL COMMENT '用户ID', `product_name` VARCHAR(128) NOT NULL COMMENT '商品名称快照', `amount` DECIMAL(12,2) NOT NULL COMMENT '订单金额', `status` TINYINT NOT NULL DEFAULT 0 COMMENT '订单状态', `created_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, `updated_at` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_user_id` (`user_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='订单表';
索引设计的思路与常见误区
索引的设计目标是让高频查询走索引，同时不拖累写入性能。基本原则是：为出现在WHERE条件、JOIN关联和ORDER BY中的字段建索引，但一张表的索引数量要控制，通常不超过五六个。每个索引都会占用存储空间，写入时也要同步维护，索引越多，插入和更新越慢。
联合索引的字段顺序非常关键，要遵循最左前缀原则。把区分度高的字段放在前面，比如(user_id, status)就要好于(status, user_id)，因为user_id的取值远多于status。同时要注意，联合索引的前导列如果不在查询条件里，整个索引就用不上，这是最常见的设计错误之一。
还有几点容易被忽略：不要在低区分度字段上单独建索引，比如性别字段单独建索引几乎没有意义；避免在索引列上使用函数或表达式，否则索引会失效； LIKE查询如果以通配符开头同样无法使用索引。索引设计完成后，一定要用EXPLAIN实际验证执行计划，确认查询确实走了预期的索引。
为扩展性留出余地
设计阶段还要考虑未来两年的业务变化。常见做法包括：字段命名预留语义空间，比如统计类字段统一用xxx_count后缀；适当增加一两个预留字段应对临时需求，但不建议大量预留，因为无意义的预留字段会让表结构变得难以理解。
对于可能快速膨胀的大表，提前规划好水平拆分键，通常是用户ID或时间。按用户维度拆分可以把同一用户的数据路由到同一个分库，避免跨库查询；按时间拆分则适合日志、流水类数据，方便归档和清理。分库分表一旦实施就很难回头，所以拆分键必须在设计初期就确定下来。
最后，所有表结构变更都应通过版本化的SQL脚本来管理，配合代码仓库做增量迁移，避免直接在生产库上手工改表。良好的文档习惯同样重要，每张表、每个字段都写清楚注释，几个月后回来看，你会感谢当初认真写注释的自己。