最近在数据库优化的时候，看到一些表在设计上使用了text或者blob的字段，单表的存储空间已经达到了近100G，这种情况再去改变和优化就非常难了
一、简介
为了清楚大字段对性能的影响，我们必须要知道innodb存储引擎的处理方式：
1、一些知识点
1.1 在InnoDB 1.0.x版本之前，InnoDB 存储引擎提供了 Compact 和 Redundant（Redundant 格式是为兼容之前版本而保留的） 两种格式来存放行记录数据，compact 和 redundant 合称为Antelope (羚羊)
对于blob，text，varchar(5120)这样的大字段，innodb只会存放前768字节在数据页中，而剩余的数据则会存储在溢出段中（发生溢出情况的时候适用），最大768字节的作用是便于创建前缀索引/prefix index，其余更多的内容存储在额外的page里，哪怕只是多了一个字节。因此，所有列长度越短越好
大字段在InnoDB里可能浪费大量空间。例如，若存储字段值只是比行的要求多了一个字节，也会使用整个页面来存储剩下的字节，浪费了页面的大部分空间。如果有一个值只是稍微超过了32个页的大小，实际上就需要使用96个页面
扩展存储禁用了自适应哈希，因为需要完整的比较列的整个长度，才能发现是不是正确的数据（哈希帮助InnoDB非常快速的找到“猜测的位置”，但是必须检查“猜测的位置”是不是正确）。因为自适应哈希是完全的内存结构，并且直接指向Buffer Pool中访问“最”频繁的页面，但对于扩展存储空间却无法使用Adaptive Hash
1.2 MySQL 5.1 中的 innodb_plugin 引入了新的文件格式：Barracuda (梭子鱼)，该文件格式拥有新的两种行格式：compressed和dynamic，两种格式对blob字段采用完全溢出的方式，数据页中只存放20字节，其余的都存放在溢出段中，因此，强烈不建议使用BLOB、TEXT、超过255长度的VARCHAR列类型；
1.3 innodb的page大小默认为16kb，innodb存储引擎表为索引组织表，树底层的叶子节点为一双向链表，因此每个页中至少应该有两行记录，这就决定了innodb在存储一行数据的时候不能够超过8k，但事实上应该更小，因为还有一些InnoDB内部数据结构要存储，5.6版本以后，新增选项 innodb_page_size 可以修改，在5.6以前的版本，只能修改源码重新编译，但并不推荐修改这个配置
