1.命名规范
数据库表名、字段名、索引名等都需要命名规范，可读性高(一般要求用英文)，让别人一看命名，就知道这个字段表示什么意思。
比如一个表的账号字段，反例如下：
acc_no,1_acc_no,zhanghao正例：
account_no,account_number-
表名、字段名必须使用小写字母或者数字，禁止使用数字开头，禁止使用拼音，并且一般不使用英文缩写。
-
主键索引名为
pk_字段名；唯一索引名为uk_字段名；普通索引名则为idx_字段名。
2.选择合适的字段类型
设计表时，我们需要选择合适的字段类型，比如：
-
尽可能选择存储空间小的字段类型，就好像数字类型的，从
tinyint、smallint、int、bigint从左往右开始选择 -
小数类型如金额，则选择
decimal，禁止使用float和double。 -
如果存储的字符串长度几乎相等，使用
char定长字符串类型。 -
varchar是可变长字符串，不预先分配存储空间，长度不要超过5000。 -
如果存储的值太大，建议字段类型修改为
text，同时抽出单独一张表，用主键与之对应。 -
同一表中，所有
varchar字段的长度加起来，不能大于65535. 如果有这样的需求，请使用TEXT/LONGTEXT类型。
3. 主键设计要合理
主键设计的话，最好不要与业务逻辑有所关联。有些业务上的字段，比如身份证，虽然是唯一的，一些开发者喜欢用它来做主键，但是不是很建议哈。主键最好是毫无意义的一串独立不重复的数字，比如UUID，又或者Auto_increment自增的主键，或者是雪花算法生成的主键等等;
4. 选择合适的字段长度
先问大家一个问题，大家知道数据库字段长度表示字符长度还是字节长度嘛？
其实在mysql中，
varchar和char类型表示字符长度，而其他类型表示的长度都表示字节长度。比如char(10)表示字符长度是10，而bigint（4）表示显示长度是4个字节，但是因为bigint实际长度是8个字节，所以bigint（4）的实际长度就是8个字节。
我们在设计表的时候，需要充分考虑一个字段的长度，比如一个用户名字段（它的长度5~20个字符），你觉得应该设置多长呢？可以考虑设置为 username varchar（32）。字段长度一般设置为2的幂哈（也就是2的n次方）。’;
5.优先考虑逻辑删除，而不是物理删除
什么是物理删除？什么是逻辑删除？
-
物理删除：把数据从硬盘中删除，可释放存储空间
-
逻辑删除：给数据添加一个字段，比如
is_deleted，以标记该数据已经逻辑删除。
物理删除就是执行delete语句，如删除account_no =‘666’的账户信息SQL如下：
delete from account_info_tab whereaccount_no =‘666’;逻辑删除呢，就是这样：
update account_info_tab set is_deleted = 1 where account_no =‘666’;为什么推荐用逻辑删除，不推荐物理删除呢？
为什么不推荐使用物理删除，因为恢复数据很困难
物理删除会使自增主键不再连续
核心业务表 的数据不建议做物理删除，只适合做状态变更。
6.每个表都需要添加这几个通用字段
如主键、create_time、modifed_time等
表必备一般来说，或具备这几个字段：
-
id：主键，一个表必须得有主键，必须
-
create_time：创建时间，必须
-
modifed_time: 修改时间，必须，更新记录时，需要更新它
-
version : 数据记录的版本号，用于乐观锁，非必须
-
remark ：数据记录备注，非必须
-
modified_by :修改人，非必须
-
creator ：创建人，非必须
7.一张表的字段不宜过多
我们建表的时候，要牢记，一张表的字段不宜过多哈，一般尽量不要超过20个字段哈。笔者记得上个公司，有伙伴设计开户表，加了五十多个字段。。。
如果一张表的字段过多，表中保存的数据可能就会很大，查询效率就会很低。因此，一张表不要设计太多字段哈，如果业务需求，实在需要很多字段，可以把一张大的表，拆成多张小的表，它们的主键相同即可。
当表的字段数非常多时，可以将表分成两张表，一张作为条件查询表，一张作为详细内容表 (主要是为了性能考虑)。
8.尽可能使用not null定义字段
如果没有特殊的理由， 一般都建议将字段定义为 NOT NULL 。
为什么呢？
-
首先，
NOT NULL可以防止出现空指针问题。 -
其次，
NULL值存储也需要额外的空间的，它也会导致比较运算更为复杂，使优化器难以优化SQL。 -
NULL值有可能会导致索引失效 -
如果将字段默认设置成一个空字符串或常量值并没有什么不同，且都不会影响到应用逻辑， 那就可以将这个字段设置为
NOT NULL。
9.设计表时，评估哪些字段需要加索引
首先，评估你的表数据量。如果你的表数据量只有一百几十行，就没有必要加索引。否则设计表的时候，如果有查询条件的字段，一般就需要建立索引。但是索引也不能滥用：
-
索引也不要建得太多，一般单表索引个数不要超过
5个。因为创建过多的索引，会降低写得速度。 -
区分度不高的字段，不能加索引，如性别等
-
索引创建完后，还是要注意避免索引失效的情况，如使用mysql的内置函数，会导致索引失效的
-
索引过多的话，可以通过联合索引的话方式来优化。然后的话，索引还有一些规则，如覆盖索引，最左匹配原则等等。。
假设你新建一张用户表，如下：
CREATE TABLE user_info_tab (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) NOT NULL,
`age` int(11) DEFAULT NULL,
`name` varchar(255) NOT NULL,
`create_time` datetime NOT NULL,
`modifed_time` datetime NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;对于这张表，很可能会有根据user_id或者name查询用户信息，并且，user_id是唯一的。因此，你是可以给user_id加上唯一索引，name加上普通索引。
CREATE TABLE user_info_tab (
`id` int(11) NOT NULL AUTO_INCREMENT,
`user_id` int(11) NOT NULL,
`age` int(11) DEFAULT NULL,
`name` varchar(255) NOT NULL,
`create_time` datetime NOT NULL,
`modifed_time` datetime NOT NULL,
PRIMARY KEY (`id`),
KEY `idx_name` (`name`) USING BTREE,
UNIQUE KEY un_user_id (user_id)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;10.不需要严格遵守 3NF，通过业务字段冗余来减少表关联
什么是数据库三范式（3NF），大家是否还有印象吗？
-
第一范式：对属性的原子性，要求属性具有原子性，不可再分解；
-
第二范式：对记录的唯一性，要求记录有唯一标识，即实体的唯一性，即不存在部分依赖；
-
第三方式：对字段的冗余性，要求任何字段不能由其他字段派生出来，它要求字段没有冗余，即不存在传递依赖；
我们设计表及其字段之间的关系, 应尽量满足第三范式。但是有时候，可以适当冗余，来提高效率。比如以下这张表
|
商品名称 |
商品型号 |
单价 |
数量 |
总金额 |
|
手机 |
华为 |
8000 |
5 |
40000 |
以上这张存放商品信息的基本表。总金额这个字段的存在，表明该表的设计不满足第三范式，因为总金额可以由单价*数量得到，说明总金额是冗余字段。但是，增加总金额这个冗余字段，可以提高查询统计的速度，这就是以空间换时间的作法。
当然，这只是个小例子哈，大家开发设计的时候，要结合具体业务哈。
