代码之家 › 专栏 › 技术社区 › NaturalBornCamper

在哪种情况下,mysql的innodb的压缩行格式会比冗余的更快/更好?

innodb mysql

1

NaturalBornCamper · 技术社区 · 7 年前

我在stackoverflow、dba和server fault上看到了很多比较,但是在特定情况下,无论使用哪种方法,在性能方面,实际上都不清楚 COMPACT 或 REDUNDANT 使用InnoDB的行格式

在某些情况下,一些简单的表是否会有明确的性能提升?例如,在一个简单的关系表中 user_roles 那会映射一个 users 带有 roles 桌子,用两个 integers 这将使磁盘上的行始终具有相同的大小?

如果这不是一个很好的例子,有没有很好的例子会有明显的区别?

谢谢!

2 回复 | 直到 7 年前

1

3

akuzminsky 7 年前

compact format对于存储字段长度稍微好一些。 redundant stores length for every field event if it's a fixed size int. compact ver然而stores only length of variable length fields.

IMO将对性能差异贡献如此之小,以至于对格式的麻烦毫无意义。


   
    
     固定大小的整数。
     
      契约
     
     但是,只存储可变长度字段的长度。
     
     
     
      IMO对性能差异的贡献如此之小,以致于不考虑格式是没有意义的。

2

1

Rick James diyism 7 年前

YMMV。

我非常肯定,在这种情况下,模式无法简单地分类为“使用该行格式的模式更好(更糟)”。

你没有提到 DYNAMIC 或 COMPRESSED 这是在后来的版本中引入的。我来谈谈我对这四种格式的看法…

最好是看看代码是否利用了任何行格式。主要的区别在于 TEXT (等)柱子。 SELECT * 要求返回所有列,但如果指定除文本列以外的所有列,则查询将可能运行得更快,因为不需要提取行外的列。

列的前767字节包含在行的主要部分中可以加快速度。但这取决于你在做什么,那只能使用文本的第一部分, 和是否存在实际利用特定情况的优化。注:“前缀索引”(例如, INDEX my_text(44) )是有用的 只有在少数情况下 )

压缩的 它的实用性值得怀疑——在缓冲池中同时拥有压缩副本和未压缩副本会产生大量开销。我很难想象压缩的情况明显更好。压缩率通常只有2:1。普通文本压缩为3:1。如果您有大的文本/blob字符串,我认为最好对选定的进行客户端压缩(减少网络带宽)。 文本 列并存储到 BLOBs .

如果一个表中只有两个整数,那么会有很多开销。见 SHOW TABLE STATUS ;它可能会说平均行长度可能是40字节。如果不包括 PRIMARY KEY .

此外,由于其他各种原因,很难看到“更快/更好”之间的差异,除非表的行数超过了,比如说,一百万行。

底线:使用默认版本。不要因为这个决定而失眠。

为了性能关注索引和查询的公式化。为了空间 ,测试您的表并返回报告。请注意,“自由空间”有很多种味道,其中大多数是不任何地方都有报告,所以如果你在桌子上打喷嚏,大小会改变。