MySQL row_format压缩与动态

Mur*_*uru 14 mysql innodb

我已经将"innodb_file_format"从"Antelope"更改为"Barracuda"bcoz,原因如下.

  1. 避免行大小限制
  2. 避免列索引大小限制

在进行文件格式更改时,我选择"row_format"作为"动态".这工作正常.

但是,我想将"row_format"从"动态"更改为"压缩"以进行数据压缩.有人能告诉我吗

  1. row_format是否与表中的COLUMN INDEXES和DATA INSERTS有关?如果是,建议使用哪个,为什么?
  2. 压缩格式会导致性能下降吗?

Bil*_*win 19

使用DYNAMIC或COMPRESSED意味着InnoDB存储的varchar/text/blob字段完全不在页面中.但除了那些每列只计算20个字节的列之外,InnoDB行大小限制没有改变; 它仍然限制在每行约8000字节.

InnoDB仅支持每列767字节的索引.您可以通过设置innodb_large_prefix=1和使用DYNAMIC或COMPRESSED行格式来提高此3072字节.

使用COMPRESSED行格式不会使InnoDB支持更长的索引.

关于性能,这是"依赖于"的情况之一.压缩通常是存储大小和压缩和解压缩的CPU负载之间的权衡.确实,这需要更多的CPU来处理压缩数据,但您必须记住,数据库服务器通常在等待I/O并且有足够的CPU资源.

但并非总是如此 - 如果对缓冲池中的数据执行复杂查询,则CPU可能会受到I/O以上的限制.因此,它取决于许多因素,例如您的数据在RAM中的适合程度,运行的查询类型以及每秒查询的数量以及硬件规格.其他任何人都无法为您的服务器上的应用程序回答太多因素.你只需要测试它.


你的评论:

一种可能性是索引不适合缓冲池.如果索引搜索需要在每个SELECT查询期间加载页面并逐出页面,则性能会显着下降.EXPLAIN分析无法告诉您索引是否适合缓冲池.

我不知道索引中有多少列或哪些数据类型的列,但如果要索引长varchar列,则应考虑使用前缀索引(或减少列的长度).

您还可以获得更多RAM并增加缓冲池的大小.


Luk*_*kas 6

COMPRESSED将压缩数据.文本将被压缩得非常好.我有几个表,之前使用过DYNAMIC,转移到COMPRESSED.

我使用MySQL 5.7

表:

  • id(int)
  • some_other_id(int)
  • text(longtext) - utf8mb4_unicode_ci~500KB /行平均值
  • updated_at(int)
  • created_at(int)

与DYNAMIC相比,它使用COMPRESSED的空间减少了80%.之前:80Gb,之后:16Gb巨大保存,而我不需要那么多数据.

其他表格并不那么引人注目,但是在有一些文本字段的情况下节省了约50%.例如,另一个来自6.4Gb - > 3.1Gb,1.5M行.

我没有更改为COMPRESSED较小的表,主要保存整数/位和类似.这些表的空间已经很小,因此不需要为它们使用更多的CPU.