高性能mysql学习笔记--数据类型

高性能mysql
四：数据类型优化
1，选择优化的数据类型
更小的通常更好:内存小；
简单就好：代价低
尽量避免null：查询null的列，很难优化，索引，索引统计也更加复杂，使用更多的储存空间。不过null改成not null带来的提升性能比较小，所以并不是首要优化的点，但是列上有索引那就避免null。
1.1 整数类型
有两种类型的数字：整数和实数
整数：TINYINT(8),SMALLINT(16),MEDIUMINT(24),INT(32),BIGINT(64)。
UNSIGNRED属性：表示不允许负值，大致可以使正数的上线提高一倍，例如：TINYINT的unsignred可以储存的范围是0～255，而INYINT的储存范围是-128～127。
实数类型：实数是带有小数部分的数字，但是不仅仅储存小数部分，也可以使用decimal存储比bigint还大的整数。
float和double类型支持使用标准的浮点运算进行近似计算。
decimal类型用于存储精确的小数。
浮点和decimal类型都可以指定精度。
1.2 字符串类型
VARCHAR和CHAR类型
这两种存在磁盘上的方式不一样。
VARCHAR
用于存储可变长字符串，它比定长类型会更节省空间，因为它仅使用必要的空间，varchar需要使用1或者2个额外字节记录字符串的长度：如果列的最大长度小于或者等于255字节，则只使用1个字节，否则使用2个字节。
varchar节省了空间，对性能有帮助，但是由于行是可变的，在update时可能使行变得比原来更长，这就需要额外的工作。
总结：varchar还是更适合的。
CHAR
char类型是定长的：mysql总是根据定义的长度分配足够的空间，char适合储存很短的字符串，或者所有值都接近一个长度，对于经常变更的数据，char也比varchar更好，因为不容易产生碎片，对于短的列，char更有效率。
总结：短的列和固定长度的值适合用char,经常变更不定长的还是用varchar把
BINARY和VARBINARY储存的是二进制字符串。
BLOB和TEXT类型
都是存储很大的数据而设计的字符串数据类型，分别采用二进制和字符串方式存储

mysql不能将blob和text列全部长度的字符串进行索引，也不能使用这些索引消除排序。
使用枚举代替字符串类型
枚举列可以把一些不重复的字符串储存成一个预定义的集合，mysql在存储美剧时非常紧凑，会根据列表值的数量压缩到一个或者两个字节中。
枚举最不好的地方是，字符串列表是固定的，添加或删除字符串必须使用alter table。
由于mysql把每个美剧值保存为整数，并且必须进行查找才能转换为字符串，所以枚举列有一些开销，通常枚举列比较小，开销还是可以控制的。
日期和时间类型
mysql能存储的最小时间粒度为秒，mysql提供了datetime和timestamp。
datetime
这个能保存大范围的值，从1001到9999年，他把时间和日期封装成YYYYMMDDHHMMSS的整数中，与时区无关，使用8个字节。
timestamp
保存了从1970年1月1号午夜以来的秒数，他和unix时间戳形同，只使用了4个字节。他的范围很小：1970年到2038年
mysql提供了from_unixtime()函数把unix时间戳转日期，提供了unix_timestamp()函数把日期转换为unix时间戳。
timestamp显示的值也依赖于时区，

通常也应该尽量使用timeastamp，因为他空间效率高，有时候人们会将unix时间戳存储为整数值，但这不会带来任何收益，用整数保存时间戳的格式通常不方便处理，不推荐这样做。
位数据类型
BIT
可以使用BIt列在一列中存储一个或多个true/false值，bit(1)定义一个包含单个位的字段，bit(2)存储2个位，bit列的最大长度是64个位。
bit的行为因存储引擎而异，myisam会打包存储所有的bit列，所以17个单独的bit列只需要17个位存储，这样myisam只使用3个字节就能存储17个bit列，其他存储引擎如memory和innodb，为每个bit列使用一个足够存储的最小整数类型来存放，所以不能节省存储空间。

这段不懂啊，不知道啥意思。一会数字一会字符串的。反正没用到过。
选择标识符（意思就是类型我们的主键）
为标识列选择合适的数据类型非常重要，一般来说更有kennel用标示列于其他值进行比较，或者通过标示列寻找其他列，标示列也可能做为外键的作用，
当选择标示列的类型时，不仅仅考虑储存类型，还需要考虑mysql对这种类型怎么执行计算和比较的。
一旦选定了一种类型，要确保在所有关联表中都使用相同的类型，类型之间需要精确匹配，包括像unsigned这样的属性，混用了不同的数据类型可能导致性能问题，而且很难发现错误。
在满足值的范围需求，并且预留未来增长空间的前提下，应该选择最小的数据类型，
整数类型：整数通常是标示列的最好选择，因为他很快并且可以使用auto_increment
枚举和set类型：不好，最好不要选择用
字符串类型：如果可以，避免用字符串类型作为标示列，因为很消耗空间，并且比数字慢，如果存uuid，则移除“-”，或者更好的做法是用unhex()函数转换uuid值为16字节的数字，并且储存一个binary(16)列中，检索时可以通过hex()函数来格式化为16进制格式。
uuid()生成的值域加密散列函数例如sha1()生成的值有不同的特征：uuid值虽然分布也不均匀，但是还是有一定的顺序，尽管如此，但还是不如递增的整数好用。
什么是schema（数据库模式）:https://blog.csdn.net/u010429286/article/details/79022484
设计数据库需要注意：
太多的列
太多关联：
    所谓实体-属性-值"(EAV)设计模式是一个常见的糟糕设计模式，mysql限制了每个关联操作最多只能有61张表，但是EAV数据库需要许多自关联，经验是如果希望查询快速且并发性好，单个查询最好在12张表内做关联。
全能枚举：不要过度使用枚举
变相枚举

范式与反范式
不知道啥是范式和反范式，看书介绍的是范式是在一张表内把一些麻烦有联系的字段拆成多张表来维护，关联清晰，反范式就是把字段聚合在一张表内，

缓存表和汇总表
汇总表：

物化视图：物化视图实际上是预先计算并且储存在磁盘上的表，可以通过各种各样的策略刷新和更新，mysql并不原生支持物化视图，可以使用其他开源工具比如flexviewa：
变更数据抓取功能，
一系列可以帮助创建和管理视图的定义的存储过程
一些可以应用变更到数据库中的物化视图的工具
计算器表
计算器表在web应用中很常见，可以用这种表缓存一个用户的朋友数，文件下载次数等，创建一个独立表来存储计数器通常是个好主意，这样可以使得计数器表小且块，使用独立的表可以避免查询缓存失败。

加快alter table操作的速度
mysql的alter table操作性能对于大表来说是个大问题，mysql执行大部分修改表结构的操作方法是用新的结构创建一个空表，从旧表中查出所有数据插入新表，然后删除旧表，这样对于大表来说是很话费内存和时间的，
常见技巧：一是先在一台不提供服务的机器上执行alter table操作，然后和提供服务的主库切换，另外一种是影子拷贝，用要求的表结构创建一张和源表无关的表，然后通过重命名和删表操作交换两张表，
不是所有的alter table操作都会引起表重建，

修改.frm文件