大家好，又见面了，我是你们的朋友全栈君。
在本次项目表结构中，有一个longtext字段，用于存储长文本，仅万条数据，InnoDB存储文件就达G级，由于是一个小项目，受限于服务器与运维人员水平，不适合使用hdfs，MongoDB等拓展技术栈来解决这种问题，因此直接对mysql存储进行优化，快速解决，利于维护。
涉及mysql基础知识
一、innodb存储引擎的处理方式
1.mysql在操作数据的时候，以page为单位
不管是更新，插入，删除一行数据，都需要将那行数据所在的page读到内存中，然后在进行操作，这样就存在一个命中率的问题，如果一个page中能够相对的存放足够多的行，那么命中率就会相对高一些，性能就会有提升
2.innodb的page大小默认为16kb
innodb存储引擎表为索引组织表，树底层的叶子节点为一双向链表，因此每个页中至少应该有两行记录，这就决定了innodb在存储一行数据的时候不能够超过8k，但事实上应该更小，有一些InnoDB内部数据结构要存储以及预留操作空间，
3.blob，text大字段
innodb只会存放前768字节在数据页中，而剩余的数据则会存储在溢出段中(发生溢出情况的时候适用)，最大768字节的作用是便于创建前缀索引/prefix index，其余更多的内容存储在额外的page里，哪怕只是多了一个字节。因此，所有列长度越短越好
4.扩展存储禁用了自适应哈希
因为需要完整的比较列的整个长度，才能发现是不是正确的数据(哈希帮助InnoDB非常快速的找到“猜测的位置”，但是必须检查“
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 举报，一经查实，本站将立刻删除。
发布者：全栈程序员-站长，转载请注明出处：https://javaforall.net/146346.html原文链接：https://javaforall.net
