反范式设计
将一些冗余字段存在多个表中，这样在查询时可以避免关联多个表，以提高查询的性能。
在更新时，如果需要一个表先查出一个 ID 再去更新另一张表，这样更新的事务会变大，而冗余一些更新条件的字段在表中，就可以进行单表更新。但如果更新这个条件字段是个高频操作，更新时需要同时更新两张表，那就需要仔细权衡。
不要设置外键
对有外键的数据进行更新，本身需要做额外的检查，也有可能需要加锁，这对于更新的性能是有影响的。所以不在数据库中设置外键，而是在业务层面去保证外键的逻辑。
增加字段的扩展性
对于业务上可能会增加删除字段的的情况，很难在一开始就能定义到所有需要的字段，所以可以考虑使用字符串或 JSON 数据类型来增加表的扩展性。对于一些需要索引的字段，则将其单独例出来，或者使用数据库本身的 JSON 方法。
数据的冷热分离
垂直分表，对于有些字段，其有些属性更新频繁，而有些数据更新较少并且数据较大，这样这字段的属性就不适合放在一个表中，而是可以将高频的数据存一张表，低频的数据存另外一张表，可以提高增删改查的性能。
建数据库集群时考虑事务
如果开始的时候只是按照同一块业务去建一个数据库，后期如果遇到多个业务需要在一个事务中完成，那就会涉及分布式事物的处理，而如果前期在数据库设计是就考虑到了这个问题，尽量的把可会放在一个事务中的数据放在同一个数据库中，那就能避免后期的分布式事务问题。比如同一用户的数据尽量放入同一数据库中。
尽量单表操作
单表操作和联表查询在性能上可能需要具体问题具体分析，但在业务逻辑高速发展时单表的处理简单，当数据量上来之后的分库分表也比有多个表要方便。如果预料到数据需要分表分库，那在初期设计时就要考虑使用分布式 ID，而不应该使用自增 ID。