高性能Mysql06-Scheme和数据类型优化

Mysql Scheme和数据类型优化

良好的逻辑设计和物理设计是高性能的基石，应该根据系统将要执行的查询语句来设计scheme。

选择优化的数据类型

• 数据类型小的通常更好。

• 尽量避免NULL，如果计划在该列上创建索引，就应该尽量避免设计成可为NULL的列。

• 简单的数据类型更好：简单的数据类型操作通常需要更少的CPU周期。

scheme设计中的陷阱

• 太多的列:Mysql的存储引擎API工作时需要在服务器层和存储引擎层之间通过行缓冲格式拷贝数据，然后在服务层将缓冲内容解码成各个列，这个操作代价是非常高的。

• 太多的关联：所谓的“实体-属性-值”（EAV）设计模式是一个常见的糟糕的设计模式。数据在存储时候涉及多张表，涉及多张表的关联（JOIN）查询自然也是效率的问题的潜在点，此外不同属性拥有的不同值类型被统一用相同的类型表示也会是一个使用的难点。Mysql限制了每个关联操作最多只能有61张表，但是EAV数据库需要许多自关联。

• 全能的枚举：防止过度的使用枚举类型。

范式和反范式

混合范式化和反范式化

范式和反范式各有优缺点：在实际应用中经常需要混用，可能使用部分范式化的scheme、缓存表、以及其他技巧。

范式的优缺点：

• 范式化的更新通常比反范式快。
• 当数据较好地范式化时，数据可更好的维护。
• 很少有多有的数据意味着检索列表数据时更少需要group by 和distinct。
• 范式化设计的scheme的缺点通常是需要关联。过多的关联不仅代价高，也可能使一些索引策略无效。

反范式的优缺点：

• 反范式化的scheme，可以很好的避免关联。