Schema与数据类型优化

一、选择优化的数据类型

更小的通常更好

应该尽量使用可以正确存储数据的最小类型，更小的数据类型通常更快，因为他们占用更少的磁盘，内存和CPU缓存，并且处理时需要的CPU周期更少

简单就好

更简单的数据类型的操作通常需要更少的CPU周期。例如，整型数字比字符操作代价更低，因为字符集和校对规则（排序规则）使字符比较相对整型数字比较更复杂。比如，应使用INTERGER存储IP地址

尽量避免NULL

通常情况下，最好指定列为NOT NULL。如果查询中包含可为NULL的列，对MySQL来说更难优化，因为可为NULL的列使得索引、索引统计和值比较非常复杂，可为NULL的列会使用更多的存储空间，当可为NULL的列被索引时，每个索引记录需要一个额外的字节。但是可为NULL的列改成NOT NULL带来的性能提升比较小，但如果计划在列上创建索引，就应该避免设计成可为NULL的列。

4.1.1 整数类型

整数类型占用空间范围

TINYINT 8 $-2^7,2^7-1$

SMALLINT 16 $-2^15,2^15-1$

MEDIUMINT 24 $-2^23,2^23-1$

INT 32 $-2^31,2^31-1$

BIGINT 64 $-2^63,2^63-1$

INT(11)只是指定显示字符的范围。不会限制值的范围

4.1.2 实数类型

实数是带有小数部分的数字，可以使用DECIMAL存储比BIGINT还大的整数。

DECIMAL类型用于存储精确的小数，支持精确计算。

4.1.3 字符串类型

varchar类型用于存储可变长字符串，比定长更节省空间。

char定长字符串，MySQL在存储时会去除char尾部的空格。

blob采用二进制的方式存储，没有排序规则和字符集。包含tinyblob,blob,mediumblob,longblob

text采用字符串的方式存储，有排序规则和字符集，包含 tinytext,text,mediumtext,longtext

4.1.4 日期和时间类型

DATETIME和TIMESTAMP

现在推荐使用DATETIME，范围更大，与时区无关，占8个字节

datetime:大范围的值 1001-9999年 YYYYMMDDhhmmss 与时区无关 8字节

timestamp: 1970-2038年存的是1970.1.1以来的秒数和时区相关 4字节

二、MySQL模式设计的陷阱

太多的列

太多的关联

NULL值

三、范式和反范式

在范式化的数据库中，每个事实数据只会出现一次

反范式化的数据库中，信息是冗余的，可能会存储在多个地方

范式优点：

范式化的更新操作更快，只需要更改较少的数据。

范式化的表更小，可以更好的放在内存里，执行操作会更快。

没有多余的数据，可以减少distinct或GROUP BY的操作

范式缺点：

通常需要表关联，，关联代价昂贵，也可能使一些索引策略无效。

反范式优点：

所有的数据都在一张表中，可以避免关联。

不关联的时候即使全表扫描，也是顺序IO。

反范式缺点：

冗余的多余数据，更新更慢。

表大，放到内存中，占用大，容易挤出热数据

四、缓存表和汇总表

缓存表：存储比较简单可以从schema其它表获取（但是获取速度比较慢）数据的表（例如，逻辑上冗余的数据）

汇总表：保存的是使用GROUP BY聚合数据的表（例如，数据不是逻辑上冗余的）

五、加快Alter table速度

Alter table操作对特大表来说，是个大问题。

可以只修改frm(表结构)文件来加快速度