首先，引见下对于InnoDB引擎储备格式的几个重心：1、InnoDB能够抉择运用同享表空间大概是自力表空间方法，创议运用自力表空间，便于治理、保护。起用innodb_file_per_table选项，5.5此后能够在线动态批改奏效，而且履行ALTERTABLExxENGINE=InnoDB将现有表转成自力表空间，早于5.5的版本，批改完这个选项后，须要重启才干奏效；2、InnoDB的datapage默许16KB，5.6版本此后，新增选项innodb_page_size能够批改，在5.6过去的版本，只可批改源码从新编译，但并不举荐批改这个建设，除非你特别明晰它有甚么优弱点；3、InnoDB的datapage在有新数据写入时，会预留1/16的空间，预留出来的空间可用于后续的新记录写入，缩小频频的新增datapage的开消；4、每个datapage，最少须要储备2行记录。因而理论上行记录最大长度为8KB，但真相上理当更小，由于再有一些InnoDB内部数据组织要储备；5、受限于InnoDB储备方法，假使数据是循序写入的话，最巴望的情景下，datapage的填充率是15/16，但正常没想法保证齐全的循序写入，因而，datapage的填充率正常是1/2到15/16。因而每个InnoDB表都最佳要有一个自增列做为主键，使得新记录写入尽大概是循序的；6、当datapage填充率不够1/2时，InnoDB会实行紧缩，释放空暇空间；7、MySQL5.6版本的InnoDB引擎现时撑持COMPACT、REDUNDANT、DYNAMIC、COMPRESSED四种格式，默许是COMPACT格式，COMPRESSED用的很少且不举荐（见下一条），假使须要用到紧缩特征的话，能够直接思量TokuDB引擎；8、COMPACT行格式比拟REDUNDANT，或许能节流20%的储备空间，COMPRESSED比拟COMPACT或许能节流50%的储备空间，但会致使TPS下落了90%。因而激烈不举荐运用COMPRESSED行格式；9、当行格式为DYNAMIC或COMPRESSED时，TEXT/BLOB之类的长列（longcolumn，也有大概是此外较长的列，不确定惟独TEXT/BLOB表率，看详细情景）会齐全储备在一个自力的datapage里，聚拢索引页中只运用20字节的指针指向新的page，这即是所谓的off-page，近似ORACLE的行迁徙，磁盘空间滥用较严峻，且I/O功用也较差。因而，激烈不创议运用BLOB、TEXT、超出长度的VARCHAR列表率；10、当InnoDB的文献格式（innodb_file_format）建设为Antelope，而且行格式为COMPACT或REDUNDANT时，BLOB、TEXT大概长VARCHAR列只会将其前字节储备在聚拢索页中（最大字节的效用是便于缔造前缀索引/prefixindex），此外更多的实质储备在额外的page里，哪怕不过多了一个字节。因而，一齐列长度越短越好；11、在off-page中储备的BLOB、TEXT大概长VARCHAR列的page是独享的，不能同享。因而激烈不创议在一个表中运用多个长列。
综上，假使在现实营业中，确切须要在InnoDB表中储备BLOB、TEXT、长VARCHAR列时，有上面几点创议：1、尽大概将所稀有据序列化、紧缩此后，储备在统一个列里，防止产生屡次off-page；2、现实最大储备长度低于的列，转成VARCHAR大概CHAR表率（假使是变长数据两者没差别，假使是定长数据，则运用CHAR表率）；3、假使无奈将一齐列调整到一个列，能够退而求其次，遵循每个列最大长度实行陈设组合后拆分红多个子表，只管是的每个子表的总行长度小于8KB，缩小产生off-page的频次；4、上述创议是在datapage为默许的16KB前提下，假使批改为8KB大概此外巨细，请自行遵循上述理论实行测试，找到最适宜的值；5、字符型列长度小于时，不论采纳CHAR照样VARCHAR来储备，大概把VARCHAR列长度界说为，都不会致使现实表空间增大；6、正常在嬉戏范畴会用到较量多的BLOB列表率，嬉戏界同业能够