互联网数据存储层，如果使用到关系型的数据库，很多公司都会采用mysql。同理传统软件的mysql使用率也是很高，怎么设计很好的数据库表结构，每个人都有自己的准则和标准。也许根据对应的业务需求不同也会有所不同。这里对一些经验来总结。

表字段的命名，要名如其意，并且尽量的简洁，因为这部分内容同样是需要存储的。

单表如果字段特别多，此时要考虑拆分表，根据数据类型或者业务类型来拆分。比如每个系统都有的用户表，用户的核心数据放在一个表中，用户的一些初始化信息，只有在第一次注册时填的内容放在一个表中，用户可能频繁修改的一些字段放在一个表中。不仅达到数据的拆分，而且对数据库存储的本身的空间进行了优化，并且根据数据的不同可以建立对应的索引，增加查询效率。

表字段类型的选择，表中会有很多不同类型的字段内容，当然我们设计表的时候肯定会设计到字典表，对于一些定性并且是可选的内容是我们都将使用字典来存储，对于mysql而言你就可以使用占用空间很小的字段类型来设置该字段TINYINT，有符号的范围是-128到127，无符号的范围是0到255。不仅选择了合适的字段类型减轻了数据存储空间，并且增加了可扩展性。这点可以参考mysql的官方文档来根据需求设定字段类型。对于时间类型的选择，首先你要考虑你的服务器使用的时间精确度，不同的数据类型需要的空间也是不一样的。

表字段冗余的问题，这个是要和具体的业务关联起来的，在设计数据库的时候虽然要求我们尽量的减少数据冗余，但是在有些业务场景下我们需要频繁的关联另外一个表查询对应表字段的一个内容，数据量小几百万都是问题不大，如果数据量是递增的，还有如果遇到分库分表，每次错跨表查询或者跨库查询都是需要消耗时间和空间的，此时合适的冗余会增加业务系统的性能，带来的问题一样是很大的，是否需要实时的更新，原数据修改了怎么办？这个不是绝对的，需要考虑具体的业务需求。

数据量大的关联查询，此时我们一定要杜绝关联查询，可以在代码级别进行数据的拼接，实现关联查询的效果。