高性能MySQL第四章 读书笔记

第4章 Schema与数据类型优化

• 数据类型的设定原则应该遵循更小的往往更好，越简单越好（如能用data就用data而不用字符串），尽量避免NULL。
• 如果数据允许NULL，对MySQL来说更难优化，因为可为NULL的列使得索引，索引统计，和值比较都比较复杂。
• TINYINT，SMALLINT，MEDIUMINT，INT，BIGINT，8,16,24,32,64位整数，还有可选的UNSIGNED属性，只保存无属性的值。
• MySQL可以为整数类型指定宽度，但是对大多数应用这是没有意义的，他不会限制值的合法范围，只是规定一些交互工具显示字符的个数。
• FLOAT和DOUBLE类型是使用标准的浮点运算进行近似计算。DECIMAL用于存储精确小数，计算过程由MySQL自己实现。
• VARCHAR需要使用1或者2个额外字节记录字符串的长度。InnoDB还会将过长的VARCHAR储存成BLOB。
• CHAR在存储的时候，如果存储时后面有空格，查询的时候会被空格剔除掉，因为CHAR填充空白也是用的空格。
• 如果使用VARCHAR（5）和VARCHAR（200）存储’hello‘，空间开销是一样的，但是，更长的列会消耗更多的内存，因为MySQL会分配固定大小的内存块来保存内部值。
• MySQL会吧BLOB和TEXT当做一个单独的对象处理，如果他们太大，会使用专门的“外部”存储区域来存储，因此每个值需要1~4个字节存储一个指针。而他们仅有的区别就是TEXT有字符集和排序规则，而BLOB没有。
• 用枚举代替有限制的字符串，枚举类型在排序的结果中，是按内部的整数存储去排序的。
• 要确保关联表之间的列的数据类型是一致的。
• 完全随机的字符串会导致INSERT和一些SELECT语句变慢，因为会写到索引的不同位置，导致页分裂，磁盘随机访问。随机值也会让缓存赖以生存的访问局部性原理失效。
• MySQL服务器层从存储引擎获取数据之后是需要解码成行数据结构的，如果列特别多，那时候CPU占用就会很高，转化的代价就非常大。
• 合理运用范式和反范式（允许冗余），缓存表和汇总表来优化查询和业务。
• 如果是用到一个统计的计数器表，可以增加多几列数据，来增加行表的使用效果。再对生成的数据进行一个汇总。统计到其中一列数据中去。
• 重申一遍，字段的数据结构尽可能用小而简单的，总是好的。