由于以下原因，我已将“innodb_file_format”从“Antelope”更改为“Barracuda”。
在更改文件格式时，我选择“row_format”作为“动态”。 这工作正常。
但是，我想将“row_format”从“动态”更改为“压缩”以进行数据压缩。有人可以告诉我吗
使用 DYNAMIC 或 COMPRESSED 意味着 InnoDB 将不适合页面的 varchar/text/blob 字段完全存储在页外。但除了那些每列仅计算 20 个字节的列之外，InnoDB 行大小限制没有改变；它仍然限制在每行 8000 字节左右。
InnoDB 仅支持每列 767 字节的索引。您可以通过设置
innodb_large_prefix=1使用 COMPRESSED 行格式并不会使 InnoDB 支持更长的索引。
关于性能，这是“视情况而定”的情况之一。压缩通常是存储大小与压缩和解压缩的 CPU 负载之间的权衡。确实，这需要更多的 CPU 来处理压缩数据，但您必须记住，数据库服务器通常正在等待 I/O 并且有空闲的 CPU 资源。
但并非总是如此——如果您对缓冲池中的数据进行复杂的查询，您可能会受到 CPU 的限制而不是 I/O 的限制。因此，这取决于许多因素，例如数据在 RAM 中的适应程度、运行的查询类型、每秒的查询数量以及硬件规格。太多因素导致其他人无法回答您服务器上的应用程序。您只需测试一下即可。
回复您的评论：
一种可能是索引不适合缓冲池。如果索引搜索需要在每个 SELECT 查询期间加载页面和逐出页面，则性能会显着降低。 EXPLAIN 分析无法告诉您索引是否适合缓冲池。
我不知道索引中有多少列或列的数据类型，但如果您要对长 varchar 列建立索引，则应考虑使用前缀索引（或减少列的长度）。
您还可以获得更多 RAM 并增加缓冲池的大小。
COMPRESSED 将压缩数据。文本将被很好地压缩。我有几个表，之前使用过 DYNAMIC，现在改为 COMPRESSED。
我使用MySQL 5.7
表：
与 DYNAMIC 相比，COMPRESSED 使用的空间减少了 80%。之前：80Gb，之后：16Gb 巨大的节省，虽然我不太需要这些数据。
其他表格没有那么引人注目，但它在有一些文本字段的地方节省了〜50％。例如。另一个从 6.4Gb -> 3.1Gb，具有 150 万行。
我没有更改为压缩的较小表，主要保存整数/位和类似的表。这些表的空间已经很小，因此不需要使用更多的 CPU。