命名

老生常谈的话题，几乎每个人都知道，但很少有人会注意，为什么把他放在第一位，在刚刚负责设计数据库的时候，没有在乎这个问题，导致后面每个开发的人都会存在疑虑，比如相同意义的字段在不同表中名称不一致，类型不一致等等。
拿到设计数据库任务时，最好先根据业务，文本型数据库关系设计出来，最后把数据库用到的所有词汇业务等统计出来，标准并统一翻译后批量替换。数据库最后sheet可以做一个英文对照表。

选择合适的字段类型

根据需求评估使用字段类型，
数字类型，不要动不动的无论范围多少，哪怕一个城市id都用bigint类型。
尽可能选择存储空间小的字段类型，就好像数字类型的，从tinyint、smallint、int、bigint从左往右开始选择
小数类型如金额，则选择 decimal，禁止使用 float 和 double。
如果存储的字符串长度几乎相等，使用 char 定长字符串类型。
varchar是可变长字符串，不预先分配存储空间，长度不要超过5000。
如果存储的值太大，建议字段类型修改为text，同时抽出单独一张表，用主键与之对应。
同一表中，所有varchar字段的长度加起来，不能大于65535. 如果有这样的需求，请使用TEXT/LONGTEXT 类型。

优先考虑逻辑删除，而不是物理删除

物理删除：把数据从硬盘中删除，可释放存储空间
逻辑删除：给数据添加一个字段，比如is_deleted，以标记该数据已经逻辑删除。
这个也不是绝对的，基础信息表因为经常要关联其他表查询信息，尽量使用逻辑删除，但一些业务表使用逻辑删除也会对SQL编写和设计增加工作量。可以考虑追加一个表，专门记录删除信息，包含删除人，删除时间，删除表名，删除记录(json)，这样无论查询还是恢复数据可以。

尽可能使用not null定义字段

设置not null 追加default 指定默认值

适当追加冗余字段

我们设计表及其字段之间的关系, 应尽量满足第三范式。但是有时候，可以适当冗余，来提高效率。
最常见的是历史记录表，如果不追加冗余字段，查询历史表时，需要关联很多基础信息表，要知道历史表通常数据量非常大，这样可以提高检索效率。

大字段

大字段可以另外存一张表，或者考虑其他类型数据库，比如mongdb

时间类型的选择

日期时间类型一直是数据库和编程方面争论不休的问题，日期存储主要分3种，日期类型、文字类型、数值类型
日期类型：用的最多的，优点直观，速度一般
文字类型：优点直观，速度最慢
数值类型：存储时间戳，优点速度最快，数据库排序、比较、查询条件等优势明显，缺点：不直观

其他

一张表的字段不宜过多，可以考虑根据主键拆分表，这个就根据业务拆分能力了
设计表时，评估那些字段需要追加索引，索引不是越多越好，加快查询速度的同时，会让更新、追加、删除