良好的逻辑设计和物理设计是高性能的基石，应该根据系统将要执行的查询语句来设计schema，这往往需要权衡各种因素。例如，反范式的设计可以加快某些类型的查询，但同时可能使另一些类型的查询变慢。比如添加计数表和汇总表时一种很好的优化查询的方式，但这些表的维护成本很高。
选择优化的数据类型
Mysql支持的数据类型非常多，选择正确的数据类型对于获得高性能至关重要。下面几个原则有助于做出更好的选择。
- 更小的通常更好
一般情况下，应该尽量使用可以正确存储数据的最小数据类型。更小的数据类型通常更快，因为他们占用更少的磁盘、内存和CPU缓存。并且处理时需要的CPU周期也更少。
但是要确保没有低估需要存储的值的范围，因为在schema中的多个地方增加数据类型的范围是一个非常耗时的操作。如果无法确定哪个数据类型是最好的，就选择你认为不会超过范围的最小类型。
- 简单就好
简单数据类型的操作通常需要更少的CPU周期。例如整型字符操作代价更低，因为字符集和校对规则（字符排序规则）使字符比较比整数比较更复杂，。例如使用日志类型存储日期和时间而不是使用字符串存储；使用整型存储IP地址等等。
- 尽量避免NULL
很多表都可能包含NULL的列，因为NULL是列的默认属性。通常情况下最好指定列为NOT NULL，除非真的需要存储NULL值。
如果查询中包含可为NULL的列，对Mysql来说更难优化，因为可为NULL的列使得索引、索引统计和值比较都更加复杂。可为NULL的列会使用更多的存储空间；可为NULL的列被索引时，每个索引记录都需要额外的字节。
通常把可为NULL的列改为NOT NULL带来的性能提升比较小，所以在进行调优时没有必要首先在现有schema中查找并修改掉这种情况。
整数类型
有两种类型的数字：整数和实数。如果存储整数，可以使用这几种整数类型：TINYINT、SMALLINT、MEDIUMINT、INT、BIGINT。分别使用8、16、24、32、64位存储空间。
整数类型有可选的UNSIGNED属性，表示不允许负值，这大致可以使正数的上限提高一倍。例如TINYINT UNSIGNED 可以存储的范围是0 ~ 255，而 TINYINT 的存储范围是 -128 ~ 127。
有符号和无符号类型使用相同的存储空间，并具有相同的性能，因此可以根据实际情况选择合适的类型。
实数类型
实数是带有小数部分的数字，然而他们不只是为了存储小数部分，也可以使用DECIMAL存储比BIGINT还大的整数。Mysql即支持精确类型，也支持不精确类型。
FLOAT和DOUBLE类型支持使用标准的浮点运算进行近似计算。
DECIMAL类型用于存储精确的小数，在Mysql5.0和更高版本DECIMAL类型支持精确计算，老版本则使用浮点运算来实现DECIMAL的计算。DECIMAL只是一种存储格式，在计算中会转换为DOUBLE类型。
字符串类型
VARCHAR 和 CHAR 类型
存储引擎存储CHAR或者VARCHAR值的方式在内存中和在磁盘上可能不一样，所以Mysql服务器从存储引擎读出的值可能需要转换另一种存储格式。
VARCHAR
用于存储可变长字符串，是最常见的字符串数据类型。他比定长类型更节省空间，因为他仅使用必要的空间。但是Mysql表使用ROW_FORMAT=FIXED创建的话，每一行都会使用定长存储，这会很浪费空间。
VARCHAR需要使用1或2个额外字节记录字符串的长度，如果列的最大长度小于或等于255字节，则只使用1个字节表示，否则使用2个字节。
VARCHAR节省了存储空间，所以对性能也有帮助。但是，由于行是变长的，在UPDATE时可能使行变得比原来更长，这就导致需要做额外的工作。如果一个行占用的空间增长，并且在页内没有更多的空间可以存储，在这种情况下，不同的存储引擎的处理方式是不一样的。InnoDB需要分裂页来使行可以放进页内。
下面这些情况下适合使用VARCHAR类型：字符串列的最大长度比平均长度大很多；列的更新少，所以碎片不是问题；使用了UTF-8这样复杂的字符集，每个字符都使用不同的字节数进行存储。
在Mysql5.0或者更高版本，Mysql在存储和检索时会保留末尾空格。
CHAR
CHAR是定长的，Mysql总是根据定义的字符串长度分配足够的空间。当存储CHAR值时，Mysql会删除所有的末尾空格。
CHAR适合存储很短的字符串，或者所有值都接近同一个长度。
BLOB和TEXT类型
BLOB和TEXT都是为存储很大的数据而设计的字符串数据类型，分别采用二进制和字符方式存储。
实际上他们分别属于不同的数据类型家族：字符类型是TINYTEXT、SMALLTEXT、TEXT、MEDIUTEXT、LONGTEXT；对应的二进制类型是BLOB、SMALLBLOB、BLOB、MEDIUBLOB、LONGBLOB。
Mysql把每个BLOB和TEXT当做一个独立的对象处理。存储引擎在存储时通常会做特殊处理。当BLOB和TEXT值太大时，InnoDB会使用专门的外部存储区域来进行存储，此时每个值在行内需要1~4个字节存储一个指针，然后在外部存储区域存储实际的值。
使用枚举代替字符串类型
枚举可以把一些不重复的字符串存储成一个预定义的集合。Mysql在存储枚举时非常紧凑，会根据列表值的数量压缩到一个或者两个字节中。Mysql在内部会将每个值在列表中的位置保存为整数，并且在表的.frm文件中保存“数字-字符串”映射关系的查找表。
枚举最不好的地方就是字符串列表时固定的，添加或删除字符串必须使用ALTER TABLE。
日期和时间类型
Mysql能存储的最小时间粒度为秒，但是Mysql也可以使用微秒级的粒度进行临时运算。
Mysql提供两种相似的日期类型：DATETIME和TIMESTAMP
DATETIME
这个类型能保存大范围的值，从1001到9999年，精度为秒。他把日期和时间封装到格式为YYYYMMDDHHMMSS的整数中，与时区无关。使用8个字节的存储空间。
默认情况下，Mysql以可排序的格式显示DATETIME值。
TIMESTAMP
保存了从1970年1月1日午夜以来的秒数，他和UNIX时间戳相同。TIMESTAMP只使用4个字节的存储空间，因此他的范围比DATETIME小得多，只能从1970到2038年。
TIMESTAMP显示的值依赖于时区。
通常情况下应该尽量使用TIMESTAMP，因为他比DATETIME空间效率更高。
位数据类型
Mysql有少数几种存储类型使用紧凑的位存储数据。所有这些位类型，不管底层存储格式和处理方式如何，从技术上来说都是字符串类型。
BIT
在Mysql5.0之前，BIT是TINYINT的同义词。Mysql5.0以后这是一个特性完全不同的数据类型。
可以使用BIT列在一列中存储一个或多个true/false值。BIT(1)定义一个包含单个位的字段，BIT(2)存储2个位，依此类推。BIT列的最大长度是64位。
Mysql把BIT当做字符串类型，而不是数字类型。
SET
如果需要保存很多true/false值，可以考虑合并这些列到一个SET数据类型，他在Mysql内部是以一系列打包的位的集合来表示的。这样就有效的利用了存储空间。并且Mysql有像FIND_IN_set()和FIELD()这样的函数。他的主要缺点是改变列的定义代价较高，需要ALTER TABLE操作。
在整数列上进行按位操作
一种替代SET的方式是使用一个整数包装一系列的位。
选择标识符
为标识列选择合适的数据类型非常重要。一般来说更有可能用标识列与其他值进行比较，或者通过标识列寻找其他列。标识列也可能在另外的表中作为外键使用，所以为标识列选择数据类型时，应该选择跟关联表中的对应列一样的类型。
当选择标识列的类型时，不仅仅需要考虑存储类型，还需要考虑Mysql对这种类型怎么执行计算和比较的。
整数类型
整数通常是标识列最好的选择，因为他们很快并且可以使用AUTO_INCREMENT。
ENUM和SET类型
对于标识列来说，ENUM和SET类型通常是一个糟糕的选择，尽管对某些只包含固定状态或者类型的静态定义表来说可能是没有问题的。ENUM和SET适合存储固定信息，如状态，类型等。
字符串类型
如果可能应该避免使用字符串类型作为标识列，因为很耗空间，并且通常比数字类型慢。
对于完全随机的字符串例如MD5，UUID产生的字符串，这些函数生成的值会任意分布在很大的空间内，这会导致INSERT以及一些SELECT语句变得很慢：
- 因为插入值会随机写到索引的不同位置，所以使得 INSERT 语句更慢，这会导致页分裂、磁盘随机访问，以及对于聚簇存储引擎产生聚簇索引碎片。
- SELECT语句会变得更慢，因为逻辑上相邻的行会分布在磁盘和内存的不同的地方。
- 随机值导致缓存对所有类型的查询语句效果都很差，因为会使得缓存赖以工作的访问局部性原理失效。
特殊类型数据
某些类型的数据并不直接与内置类型一致。例如低于秒级精度的时间戳。
另一个例子就是IPv4地址。我们经常用字符串来存储IP地址。然后实际上是32位无符号整数。
Mysql schema设计中的陷进
太多的列
Mysql的存储引擎API工作时需要再服务器层和存储引擎层之间通过行缓冲格式拷贝数据，然后在服务器层将缓冲内容解码成各个列。从行缓冲中将编码过的列转换成行数据结构的代价非常高。转换的代价依赖于列的数量。
太多的关联
所谓的“实体-属性-值”设计模式是一个常见的糟糕的设计模式，尤其是在Mysql中。Mysql限制了每个关联操作最多只能有61张表。如果希望查询执行的快速且并发性好，单个查询最好在12个表内。当然在实际开发过程过很少会有这么多表的关联。
全能的枚举
防止过度使用枚举。
变相的枚举
枚举列允许在列中存储一组定义值中的单个值，集合SET列则允许在列中存储一组定义值中的一个或多个值。
范式和反范式
对于任何给定的数据通常都有很多种表示方法，从完全的范式化到完全的反范式化，以及两者的折中。在范式化的数据库中，每个事实数据会出现并且只出现一次。相反，在反范式化的数据库中，信息是冗余的，可能会存储在多个地方。
范式的优点和缺点
优点
范式化的更新操作通常比反范式化要快。
当数据较好地范式化时，就只有很少或者没有重复数据，所以只需要修改更少的数据。
范式化的表通常更小，可以更好地放在内存里，所以执行操作会更快。
很少有多余的数据意味着检索列表数据时更少需要DISTINCT或者GROUP BY语句。
缺点
通常需要更多的关联。稍微复杂一点的查询在符合范式的schema上都需要至少一次关联。
反范式的优点和缺点
反范式化的schema因为所有数据都在一张表中，可以很好地避免关联。
混用范式化和反范式化
缓存表和汇总表
有时提升性能最好的方法是在同一张表中保存衍生的冗余数据。然而有时也需要创建一张完全独立的汇总表或缓存表。
物化视图
物化视图实际上是预先计算并且存储在磁盘上的表，可以通过各种各样的策略刷新和更新。Mysql并不原生支持物化视图。
计数器表
加快ALTER TABLE操作的速度
Mysql的ALTER TABLE操作的性能对大表来说是个大问题。Mysql执行大部分修改表结构操作的方法是用新的结构创建一个空表，从旧表中查出所有数据插入新表，然后删除旧表。这样的操作可能需要花费很长的时间，如果内存不足而表又很大，而且还有很多索引的情况下尤其如此。
只修改.frm文件
修改表的.frm文件时很快的，但是Mysql有时候会在没有必要的情况下重建表。
下面的一些操作可能不需要重建表：
- 移除一个列的AUTO_INCREMENT属性。- 增加、移除或者修改ENUM和SET常量。
快速创建MyISAM索引
为了高效地载入数据到MyISAM表中，有一个常用的技巧是先禁用索引，载入数据，然后重新启动索引。因为构建索引的工作呗延迟到数据完全加载之后了，这个时候可以通过排序来构建索引。这样做会使索引树的碎片更少，更紧凑。
但是这个方法对唯一索引无效，因为DISABLE KEYS 只对非唯一索引有效。MyISAM会在内存中构造一个唯一索引并且为载入的每一行数据检查唯一性，一旦索引的大小超过了有效内存大小，载入操作就会越来越慢。
在InnoDB中有一个类似的技巧，依赖于InnoDB的快速在线索引创建功能。先删除所有的非唯一索引，然后增加新的列，最后重新创建删除掉的索引。
