选择优化的数据结构
选择某个字段的类型时，有几个原则可以尝试遵守
1.更小通常更好，因为它们占有更小的磁盘、内存和CPU缓存，且处理时所需的时间周期比较少
2.尽量选择结构简单的数据结构，比如整型就比字符简单，字符有编码格式和排序规则。
3.尽量避免NULL，尤其对于需要建索引的列，可为NULL的列，会使得索引、索引统计和值比较都更复杂。只有在大量稀疏数据且使用INNODB的场景下，使用该列为null才会带来一定的空间效率。如非必须，大多数情况，都不要置某列可为NULL。
整数类型
TINYINT(8bit),SMALLINT(16bit),MEDIUMINT(24bit),INT(32bit),BIGINT(64bit).
整数还可选UNSIGNED属性，表示不允许负值。
实数类型
带有小数部分的类型，或者大于BIGINT的整型。
FLOAT\DOUBLE类型都是支持使用标准浮点运算进行近似计算的，具体如果运算需要看所使用的平台，它是不精确的（所以一般不用它来存储钱啊，之类的需要精确存储的内容）
DECIMAL类型可用于存储精确的小数，最多65个数字，支持精确运算。高精度运算由MySQL自行提供，所以速度小于原生浮点运算。
如果对精度要求没那么高，可以将浮点数扩大为整数，然后进行相应的运算(比如1.6666精度要求为0.01,就可以变为166，然后进行相关运算)，来避免浮点运算的不精确和DECIMAL运算的高代价。
字符串类型
VARCHAR
用于可变长字符串，比定长字符串更节省空间，它仅使用必要的空间，除了字符串所需空间，还另外使用1~2字节来存储字符串的长度。不过由于是可变长的，如果需要扩容，则会有额外的工作，MyISAM是将行拆分成不同的片段存储，而InnoDB则需要分裂页的方式，使行能放进页内。
在字符串列的最大长度比平均长度大很多；列的更新较少；使用UTF-8这种复杂的字符集。
VARCHAR就像一个List< List>里面存的字符的长度可不固定
CHAR就像char[][] 一旦决定了列数就无法改变了。（不过这里行数是可以改变的）
注意这仅是空间开销，内存分配则偏向于分配一个固定的大小，所以还是需要多少，分配多少来得好(比如VARCHAR(5)合适就不要用VARCHAR(100))
CHAR
定长的，当存储为CHAR时，在不足的长度会用空格进行填充，相当于删除所有的末尾空格（VARCHAR不会，5.0以后）。
CHAR适合存储很短的字符串，或者所有值长度都比较平均的字段。
BINARY和VARBINARY
与CHAR和VARCHAR类似，不过存储的二进制字符串，存储的不是字符而是字节码，大小写敏感。
BINARY使用\0填充
BLOB和TEXT
BLOB对应以二进制存储大字符串，当VARCHAR很大时INNODB便会用这种结构代替VARCHAR，可分为TINYBLOB；SMALLBLOB；SMALLBLOB；BLOB；MEDIUMBLOB；LONGBLOB.
TEXT 对应以字符类型存储的大字符串类型，分为TINYTEXT;SMALLTEXT;TEXT;MEDIUMTEXT;LONGTEXT。
它们之间的不同仅是BLOB类型存储的是二进制数据且没有排序规则和字符集。
它们只依靠每个列最前max_sort_length字节做排序。如果仅需要排序一部分，可减小max_sort_length的配置，或者使用ORDER BY SUSTRING(column,length);
与其他类型不同，MySQL会将这俩类型当作独立的对象除了，如果过大时InnoDB会使用专门的外部空间存储，这时的"值"就是1~4字节的指针。
ENUM
MySQL里居然也有枚举类型，枚举类型是数字-字符串的映射关系。
排序方式是按照数字顺序排序的。
也可使用FIELD函数指定顺序。指定之外的顺序按照自然顺序排列排于指定之前。
如果字符串类型变动比较频繁就不宜采用这种格式，优势在于占用空间小，节省IO。
时间和日期类型
DATETIME
YYYYMMDDHHMMSS，与时区无关，使用8个字节的存储空间。
TIMESTAMP
1970年1月1日午夜以来的秒数~2038年(之后可咋整呀)
依赖于时区。空间效率高于DATETIME
位数据类型
技术上来说是个字符串类型
BIT
8的版本并没有像书中所诉的显示它的ASCII码对应的结果，而是直接显示的二进制。
总之谨慎使用。
SET
如果保存较多的true/false值，可考虑合并这些列到SET数据结构中。可以有效的利用储存空间。缺点和枚举一样，改变列的定义的代价较高，需要使用ALTER TABLE.
hhh俺read打错了
选择标识符
整数是标识列最好的选择，快且可用自增自动生成。