MySQL数据库设计常犯的错以及对性能的影响

1.过分的反范式化为表建立太多的列

　　我们在设计数据库的结构时，比较容易犯的第一个错误就是对表进行了过分的反范式化的设计，这就容易造成了表中的列过多，虽然说Mysql允许为一个表建立很多的列，但是由于Mysql的插件式架构的原因，前面博客已经有介绍，Mysql的服务器层和存储引擎层是分离的，Mysql的存储引擎API工作时需要把服务器层和存储引擎层之间通过缓冲格式来拷贝数据，然后在服务器层将缓冲层的数据解析成各个列，这个操作过程成本是非常高的，特别是对于MyISAM的变长结构，和Innodb这种行结构在解析时还必须进行转换，这个转换的成本呢就依赖于列的数量，所以，如果一个表的列过多，在使用这个表时就会带来额外过多的cpu消耗。所以在进行表设计的时候一定要注意，不要把表相关的所有列都放在一个表中，而是要按照范式化适当的对表进行拆分，关于什么是范式化，会另外的详细介绍。

 

2.过分的使用范式化设计造成了太多的表关联

　　对数据库的设计过分的使用了范式化设计的思路，对于任何的查询都要关联很多个表，通过前面的介绍，我们知道对Mysql进行表关联查询成本是非常高的，而且性能也会随着关联表的增加而下降，所以呢Mysql对表关联的数量进行了限制，Mysql最多只可以关联61个表，这个限制呢虽然对于大多数应用来说已经足够了，但是我们为了Mysql的性能还是要尽量减少关联的表，关联的表数量最好在10个以内，这就要求我们在进行数据库设计时候要进行适当的反范式化设计，把经常使用的两个小表合成一个大表，这样做对提升数据库的性能和sql查询的性能都是很有帮助的 。

 

3.在OLTP环境中使用不恰当的分区表

　　分区表是一个好东西，可以帮助我们把一个大表在物理存储上按照分区键分成多个小表，这里要注意了，分区表和我们常说的分库分表是有区别的，分区表是在同一个数据库实例下进行的，而物理存储上分成多个小表但是在使用时逻辑上还是使用一个表；而分库分表所要做的操作不止是在物理上进行拆分而且逻辑上也会拆分多个表，而且分库分表后多个表通常不是在一个数据库实例下的。在使用分区表时，分区键的选择非常关键，如果分区键的选择不恰当，就会造成查询时跨多个分区查询，这样不仅不会提升数据库的性能，而且还会降低数据库的查询性能，所以建议在OLTP环境中使用分区表一定要注意，分区表最好还是在OLAP环境使用，或者对于一些日志表使用还是比较合适的。

4.使用外键约束保证事务的完整性

　　 我们都知道InnoDB存储引擎是事务型存储引擎，它是支持事务和外键的，所以很多开发人员喜欢使用外键约束来保证数据的完整性，但是这样的效率是非常低的，因为在对使用外键的表进行修改时，Mysql都会对外键约束来进行检查，这样呢就带来了额外的锁的开销，降低了数据库修改的效率；另外使用外键，在进行数据库备份、恢复或者手动进行数据归档维护也会有问题，比如：我们不能使用truncate table对表快速的进行清空操作， 只能使用delete from进行，这样在主从复制的环境下对一个大表的数据环境清理复杂度就会变得很高，所以强烈建议不要使用外键约束，但是在关联键上建立相关的索引还是必须的