我一直在尝试一些压缩innodb表。我的理解是，这仅在梭子鱼格式下可用。
我看到innodb_file_format是动态的，因此我无需跳动就可以切换。我应该意识到这样做的任何含义。我只能说意味着将使用该格式创建新表或随后更改的表。这一切对吗？
我希望不必经历所有表的转换。犹太洁食器是否在同一表空间中同时存在羚羊和梭子鱼表？即使可以正常工作，也有什么需要注意的地方吗？
从我阅读并从测试中收集的信息来看，答案是：是的。是。我不确定。
更新
自从这篇文章发布以来，我一直在各种实例中运行一些动态表和一些压缩表。此外，我当时忽略了阅读http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html。
启用给定的innodb_file_format后，此更改仅将
应用于新创建的表，而不是现有的表。如果您确实创建了一个新表，则包含该表的表空间将被标记为该表的功能所需的“最早”或“最简单”文件格式。例如，如果启用文件格式梭子鱼，并创建
未压缩且不使用的新表
因此即使允许梭子鱼，表也将被创建为羚羊。除非您将每个表都指定为row_format动态表或压缩表，否则混合是不可避免的。
没有迹象表明您在引入第一个梭子鱼表时应该进行完整的转储和重新加载（例如在升级主要版本的mysql时建议这样做）。
#1 楼
因此，我迟到了4年才回答这个问题：InnoDB文件格式是在InnoDB独立于MySQL Server的时候构思的（例如：MySQL 5.1可以运行两种不同的格式
您不希望运行梭子鱼（2012年）的原因是，它可能会降低降级MySQL的灵活性（即，升级失败后，您想移回无法升级的版本）。阅读较新的格式）。也就是说，应该没有技术原因才能使Antelope更好。
在MySQL 5.7中，不建议使用
innodb_file_format选项。由于MySQL和InnoDB不再独立，因此InnoDB可以使用MySQL升级规则以及需要向后兼容的规则。无需混淆设置！在MySQL 5.7中，默认设置切换为
Barracuda/DYNAMIC。由于当前所有受支持的MySQL版本都可以读取此格式，因此可以安全地离开Antelope并继续降级。在MySQL 5.7服务器上，Antelope表将在下次重建表时升级到
Barracuda/DYNAMIC（OPTIMIZE TABLE）等等）。除非它们是使用ROW_FORMAT=oldrowformat专门创建的。在MySQL 8.0中，选项
innodb_file_format被删除了。MySQL 5.7还引入了选项
innodb_default_row_format，默认情况下为DYNAMIC。这解决了更新中的重点。#2 楼
Just give a try!!!
mysql> select version();
+------------+
| version() |
+------------+
| 5.5.21-log |
+------------+
1 row in set (0.00 sec)
mysql> show variables like "%innodb_file%";
+--------------------------+----------+
| Variable_name | Value |
+--------------------------+----------+
| innodb_file_format | Antelope |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antelope |
| innodb_file_per_table | ON |
+--------------------------+----------+
4 rows in set (0.00 sec)
mysql> SET GLOBAL innodb_file_format = barracuda;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like "%innodb_file%";
+--------------------------+-----------+
| Variable_name | Value |
+--------------------------+-----------+
| innodb_file_format | Barracuda |
| innodb_file_format_check | ON |
| innodb_file_format_max | Antelope |
| innodb_file_per_table | ON |
+--------------------------+-----------+
4 rows in set (0.00 sec)
mysql> SET GLOBAL innodb_file_format_max = barracuda;
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like "%innodb_file%";
+--------------------------+-----------+
| Variable_name | Value |
+--------------------------+-----------+
| innodb_file_format | Barracuda |
| innodb_file_format_check | ON |
| innodb_file_format_max | Barracuda |
| innodb_file_per_table | ON |
+--------------------------+-----------+
4 rows in set (0.00 sec)
I had observed a single line logged in Error Log file :
[root@dhcppc0 Desktop]# tail -1 /usr/local/mysql/data/dhcppc0.err
120402 11:26:52 [Info] InnoDB: the file format in the system tablespace is
now set to Barracuda.
After switching to barracuda file format, I could also access my Database
and tables without any error :
mysql> show databases;
+--------------------+
| Database |
+--------------------+
| information_schema |
| mysql |
| opentaps1 |
| performance_schema |
| test |
+--------------------+
5 rows in set (0.00 sec)
mysql> use opentaps1;
Database changed
mysql> select count(*) from product;
+----------+
| count(*) |
+----------+
| 3244 |
+----------+
1 row in set (0.42 sec)
mysql> show engines;
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| Engine | Support | Comment | Transactions | XA | Savepoints |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
| MRG_MYISAM | YES | Collection of identical MyISAM tables | NO | NO | NO |
| CSV | YES | CSV storage engine | NO | NO | NO |
| MyISAM | YES | MyISAM storage engine | NO | NO | NO |
| BLACKHOLE | YES | /dev/null storage engine (anything you write to it disappears) | NO | NO | NO |
| MEMORY | YES | Hash based, stored in memory, useful for temporary tables | NO | NO | NO |
| InnoDB | DEFAULT | Supports transactions, row-level locking, and foreign keys | YES | YES | YES |
| ARCHIVE | YES | Archive storage engine | NO | NO | NO |
| PERFORMANCE_SCHEMA | YES | Performance Schema | NO | NO | NO |
| FEDERATED | NO | Federated MySQL storage engine | NULL | NULL | NULL |
+--------------------+---------+----------------------------------------------------------------+--------------+------+------------+
9 rows in set (0.00 sec)
mysql> show engine innodb status\G
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
120402 11:36:29 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 18446744073709534037 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 12 1_second, 12 sleeps, 1 10_second, 2 background,
2 flush
srv_master_thread log flush and writes: 12
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 5, signal count 5
Mutex spin waits 2, rounds 60, OS waits 2
RW-shared spins 3, rounds 90, OS waits 3
RW-excl spins 0, rounds 0, OS waits 0
Spin rounds per wait: 30.00 mutex, 30.00 RW-shared, 0.00 RW-excl
------------
TRANSACTIONS
------------
Trx id counter F01
Purge done for trx's n:o < 0 undo n:o < 0
History list length 0
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION F00, not started
MySQL thread id 1, OS thread handle 0x7f38309f9710, query id 28 localhost
root
show engine innodb status
--------
FILE I/O
--------
I/O thread 0 state: waiting for completed aio requests (insert buffer
thread)
I/O thread 1 state: waiting for completed aio requests (log thread)
I/O thread 2 state: waiting for completed aio requests (read thread)
I/O thread 3 state: waiting for completed aio requests (read thread)
I/O thread 4 state: waiting for completed aio requests (read thread)
I/O thread 5 state: waiting for completed aio requests (read thread)
I/O thread 6 state: waiting for completed aio requests (write thread)
I/O thread 7 state: waiting for completed aio requests (write thread)
I/O thread 8 state: waiting for completed aio requests (write thread)
I/O thread 9 state: waiting for completed aio requests (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
554 OS file reads, 7 OS file writes, 7 OS fsyncs
-0.01 reads/s, 16384 avg bytes/read, -0.00 writes/s, -0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 276707, node heap has 15 buffer(s)
-0.15 hash searches/s, -0.12 non-hash searches/s
---
LOG
---
Log sequence number 221536390
Log flushed up to 221536390
Last checkpoint at 221536390
0 pending log writes, 0 pending chkp writes
10 log i/o's done, -0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 137363456; in additional pool allocated 0
Dictionary memory allocated 3476070
Buffer pool size 8192
Free buffers 7635
Database pages 542
Old database pages 220
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
-0.00 youngs/s, -0.00 non-youngs/s
Pages read 542, created 0, written 1
-0.01 reads/s, -0.00 creates/s, -0.00 writes/s
Buffer pool hit rate 980 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead -0.00/s, evicted without access -0.00/s, Random read ahead
-0.00/s
LRU len: 542, unzip_LRU len: 0
I/O sum[0]:cur[238], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread process no. 2937, id 139879303665424, state: waiting for server
activity
Number of rows inserted 0, updated 0, deleted 0, read 3244
-0.00 inserts/s, -0.00 updates/s, -0.00 deletes/s, -0.18 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
1 row in set (0.00 sec)
#3 楼
如果您真的想使用梭子鱼格式使用InnoDB，则应将所有内容都mysqldump到/root/MySQLData.sql之类。这使得数据文件格式独立。使用另一个具有新的ibdata1和innodb_file_per_table的MySQL实例（可选，根据我的个人喜好）。在ibdata1为空的情况下更改文件格式。然后，重新加载/root/MySQLData.sql并处理数据。
我听到了一些关于PostgreSQL必须进行tweek设置才能使8.2.4数据库与9.0.1二进制一起使用的恐怖故事。如果我们尝试使两种文件格式都驻留在相同的系统表空间（ibdata1）和/或
.ibd文件中（如果我们知道此类设置），则可能适用相同的说法。就洁...
没有人应该将肉和乳制品存储在同一冰箱中
没有人应该将公牛和驴子放在同一个轭中（申命记22:10）
没有人应该在同一ibdata1中存储
Antelope和Barracuda UPDATE 2013-07-05 14:26 EDT
我刚刚在ServerFault中回答了这个问题：设置MySQL INNODB压缩KEY_BLOCK_SIZE。这使我回想起我在DBA StackExchange中回答的所有问题，讨论了
Barracuda格式，并且发现了我的这个旧帖子。我将在此处放置相同的信息... 根据有关梭子鱼的InnoDB压缩的MySQL文档
压缩和InnoDB缓冲池
在压缩的InnoDB表中，每个压缩页（无论是1K，2K，4K还是8K）都对应于一个16K字节的未压缩页。要访问页面中的数据，InnoDB从磁盘中读取压缩的页面（如果缓冲池中还没有压缩的页面），然后将页面解压缩为其原始的16K字节格式。本节描述InnoDB如何针对压缩表的页面管理
缓冲池。
为了最大程度地减少I / O并减少解压缩页面的需求，缓冲池有时会同时包含数据库页面的压缩形式和未压缩形式。为了为其他必需的数据库页面腾出空间，
InnoDB可以从缓冲池中“退出”未压缩的页面，而
将压缩的页面保留在内存中。或者，如果一段时间没有访问页面，则可以将页面的压缩形式写入磁盘，以释放其他数据的空间。因此，在任何给定时间，
缓冲池都可以包含页面的压缩形式和未压缩形式，或者仅包含页面的压缩形式，或者都不包含。 InnoDB使用最近最少使用（LRU）列表来跟踪哪些页面要保留在内存中以及哪些页面要退出，以便“热”或频繁访问的数据倾向于保留在内存中。当访问压缩表时，InnoDB使用自适应LRU算法来实现内存中压缩和未压缩页面的适当平衡。
这种自适应算法对系统是否正在运行很敏感
。 />以I / O绑定或CPU绑定的方式。目的是避免在CPU繁忙时避免花费太多的处理时间来解压缩页面，并且
当CPU拥有可用于解压缩的空闲周期时避免进行过多的I / O
。压缩页（可能已经在内存中）。
当系统受I / O限制时，该算法更喜欢逐出页的未压缩副本而不是两个副本，以腾出更多空间
，使其他磁盘页面成为驻留内存的磁盘。当系统受CPU限制时，InnoDB宁愿退出压缩页面和
未压缩页面，以便更多的内存可用于“热”页面，并且
减少了解压缩数据的需求只能以压缩形式存储在内存中。
请注意，InnoDB缓冲池必须加载数据页和读取的索引页以完成查询。首次读取表及其索引时，压缩页必须解压缩为16K。这意味着您将在缓冲池（压缩和未压缩的数据页）中拥有两倍的数据内容。
如果在缓冲池中正在进行重复的数据内容，则需要将innodb_buffer_pool_size增加新压缩率的较小线性因子。操作方法如下：
SCENARIO
您有一个带有8G缓冲池的数据库服务器
您使用
key_block_size=8运行压缩/>
8是50.00%的16 50.00%是8G 4G到innodb_buffer_pool_size（12G + 8G）您使用
4G进行压缩key_block_size=4是4的25.00% 16 25.00%的值是8G 将
2G升至innodb_buffer_pool_size（10G + 8G）您使用
2G进行压缩key_block_size=2是2的12.50% 16的12.50%是8G 将
1G增大到innodb_buffer_pool_size（9G + 8G）您使用
1G执行压缩key_block_size=1是1的06.25% 16的06.25%是q4 312079q（8G）将
0.5G提高至512M（innodb_buffer_pool_size（8704M）+ 8G）故事的目的：InnoDB缓冲池只需要额外的呼吸空间处理压缩数据和索引页时。