命名规范别随便
建表的时候，很多人图省事，直接用中文拼音或者缩写，比如 user_info 改成 us_inf。时间一长，自己都看不懂。建议表名和字段名都用英文小写，下划线分隔，比如 order_detail、create_time。这样别人一看就明白，后期维护也方便。
另外，避免使用数据库关键字作为字段名，比如 order、group、desc。虽然加反引号能解决，但后续写SQL容易出错，没必要给自己找麻烦。
主键设置要合理
每张表最好都有一个主键，不然数据没法唯一标识。常见的做法是加一个自增ID，比如 id INT AUTO_INCREMENT PRIMARY KEY。不要拿身份证号或者手机号当主键，这些信息可能变更，而且占用空间大，影响索引效率。
字段类型别乱选
看到数字就用 INT，看到文本就用 VARCHAR(255)，这是很多新手的通病。其实字段类型要根据实际需求来定。比如年龄，用 TINYINT 就够了，没必要上 INT；状态字段只有几个值，可以用 ENUM('active', 'inactive')，既省空间又防脏数据。
时间字段记得用 DATETIME 或 TIMESTAMP，别存字符串。否则你想查“最近一周的订单”，就得把时间一个个转换，效率低还容易出错。
索引不是越多越好
有人觉得索引越多查询越快，其实不然。索引会加快查询，但会拖慢插入和更新。比如你在每个字段上都加索引，那每次写数据都要更新多个索引树，性能反而下降。
重点给常用来做查询条件的字段加索引，比如 user_id、order_status。联合索引注意顺序，遵循最左匹配原则。比如你建了 INDEX(user_id, status)，那查 user_id = 1 能用上，但只查 status = 'paid' 就用不上。
别忘了设置默认值
有些字段其实有明确的默认状态。比如用户注册，默认是激活状态；订单创建，默认是待支付。这些在建表时就可以指定默认值，避免程序层反复判断。
CREATE TABLE `users` (
`id` INT AUTO_INCREMENT PRIMARY KEY,
`username` VARCHAR(64) NOT NULL,
`status` TINYINT DEFAULT 1,
`create_time` DATETIME DEFAULT CURRENT_TIMESTAMP
);像 create_time 直接设默认值，程序不用手动传时间，减少出错可能。
预留扩展空间
表一旦上线，改结构就没那么容易了。尤其是生产环境，加个字段可能得停服或者做数据迁移。所以建表时稍微想远一点，比如用户表要不要支持多设备登录？是否需要记录最后登录IP？这些字段可以先加上，哪怕暂时不用，比后期补要轻松。
当然也不是让你把所有可能用到的都加上，那样会臃肿。把握一个度：常见业务场景中大概率会用到的，可以提前规划。