SQL表结构设计直接决定了数据库的性能上限和可维护性，错误的设计往往会在业务数据量增长后引发一系列问题，从字段类型的选择到表间关系的梳理，每个环节都有需要遵循的规范与优化方向。
字段设计的规范要点
字段是表的最小组成单元，设计时需要优先关注类型和命名两个核心维度。
字段类型选择
优先选择和业务场景匹配的最小可用类型，避免盲目使用大类型浪费存储空间。比如存储用户年龄时，使用TINYINT就足够覆盖0到255的范围，不需要用INT；存储固定长度的唯一编码时，使用CHAR比VARCHAR的查询效率更高。
时间类型需要根据场景区分：如果需要精确到秒且需要时间计算，优先用DATETIME或者TIMESTAMP；如果只需要存储日期，用DATE即可，避免存储冗余的时间部分。
字段命名规范
命名需要统一风格，建议使用下划线分割单词，避免使用拼音或者生僻缩写。比如用户表的主键可以命名为user_id，而不是yhid或者uid（如果团队没有统一uid规范的话）。同时字段名要能清晰体现含义，比如register_time就比time1更容易理解。
范式与反范式的平衡
范式设计的核心是减少数据冗余，一般遵循第三范式就能满足大部分场景的需求，但也不是范式等级越高越好。
第三范式要求表中的字段不能存在对非主键字段的依赖，比如用户表中如果同时存储了user_id、dept_id、dept_name，那么dept_name依赖于dept_id，而dept_id依赖于user_id，就违反了第三范式，这种情况应该把部门信息单独拆分为部门表，用户表只保留dept_id。
但如果业务中有高频的关联查询场景，比如订单表每次查询都需要关联用户表获取用户昵称，这时候可以适当做反范式设计，在订单表中冗余存储user_nickname字段，减少关联查询的开销，不过需要注意冗余字段的更新同步问题。
约束与索引的设计优化
约束设置
合理的约束能保证数据的完整性，常用的约束包括主键约束、非空约束、唯一约束、外键约束。
每个表都应该设置主键，优先使用自增的整数类型作为主键，避免使用业务字段（比如身份证号）作为主键，因为业务字段可能存在更新风险，而且长度更长会影响索引效率。对于非空字段，一定要设置NOT NULL约束，避免存储NULL值导致索引失效或者查询判断出错。
外键约束可以根据场景选择是否使用，如果是高并发的业务场景，外键的级联操作可能会影响性能，可以在业务层做数据一致性校验，替代数据库层的外键约束。
索引适配
索引不是越多越好，每个额外的索引都会增加写入数据时的开销，同时占用存储空间。优先给查询条件中高频出现的字段、关联查询的关联字段创建索引，比如用户表的mobile字段如果经常用来做登录查询，就可以创建唯一索引。
避免在低区分度的字段上创建索引，比如用户表的gender字段只有男、女两个值，创建索引的收益极低，反而会增加维护成本。
实践示例
下面是一个符合规范的用户表设计示例，涵盖了上述提到的设计要点：
-- 创建用户表 CREATE TABLE `user` ( `user_id` INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户ID，主键', `user_name` VARCHAR(50) NOT NULL COMMENT '用户名称', `mobile` VARCHAR(20) NOT NULL COMMENT '手机号', `gender` TINYINT NOT NULL DEFAULT 0 COMMENT '性别，0未知，1男，2女', `register_time` DATETIME NOT NULL COMMENT '注册时间', `dept_id` INT UNSIGNED NOT NULL COMMENT '所属部门ID', PRIMARY KEY (`user_id`), UNIQUE INDEX `idx_mobile` (`mobile`), INDEX `idx_dept_id` (`dept_id`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户信息表';
这个表使用了自增整数作为主键，字段类型都选择了匹配业务的最小类型，设置了非空约束和唯一索引，同时给关联字段dept_id创建了普通索引，符合大部分业务场景的设计要求。