Então, estou respondendo a esta pergunta com quase 4 anos de atraso:

• Os formatos de arquivo InnoDB foram concebidos em uma época em que o InnoDB era independente do MySQL Server (por exemplo: o MySQL 5.1 podia executar duas versões diferentes do InnoDB).

• A razão pela qual você não gostaria de executar o Barracuda (em 2012) é que ele poderia reduzir a flexibilidade no downgrade do MySQL (ou seja, após uma atualização com falha, você deseja voltar para uma versão que não pode ler um formato mais recente). ou seja, não deve haver razões técnicas pelas quais o Antelope é melhor.

• No MySQL 5.7 a innodb_file_formatopção foi preterida. Como o MySQL e o InnoDB não são mais independentes, o InnoDB pode usar as regras de atualização do MySQL e qual compatibilidade com versões anteriores é necessária. Nenhuma configuração confusa necessária!

• No MySQL 5.7, o padrão mudou para Barracuda/DYNAMIC. Como todas as versões do MySQL atualmente suportadas podem ler este formato, é seguro se afastar do Antelope e ainda oferecer downgrade.

• Em um servidor MySQL 5.7, as tabelas Antelope serão atualizadas para Barracuda/DYNAMICa próxima reconstrução da tabela (OPTIMIZE TABLE etc). Isso é, a menos que eles tenham sido criados especificamente com ROW_FORMAT=oldrowformat.

• No MySQL 8.0, a opção innodb_file_formaté removida.

O MySQL 5.7 também apresenta a opçãoinnodb_default_row_format , cujo padrão é DYNAMIC. Isso aborda o ponto em sua atualização.

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)

Se você realmente quer jogar com o InnoDB usando o formato Barracuda, você deve mysqldump tudo para algo como /root/MySQLData.sql. Isso torna o formato do arquivo de dados independente.

Use outra instância do MySQL com um novo ibdata1 e innodb_file_per_table (opcional, minha preferência pessoal). Altere o formato do arquivo com ibdata1 vazio. Em seguida, recarregue /root/MySQLData.sql e brinque com os dados.

Eu ouvi pequenas histórias de terror sobre o PostgreSQL ter que ajustar as configurações para obter um banco de dados 8.2.4 para trabalhar com binários 9.0.1. A mesma história poderia se aplicar se tentássemos fazer com que ambos os formatos de arquivo residissem no mesmo tablespace do sistema (ibdata1) e/ou .ibdarquivo se estivermos cientes de tais configurações.

Quanto a ser kosher...

• Ninguém deve armazenar carne e laticínios na mesma geladeira
• Ninguém deve colocar um touro e um jumento sob o mesmo jugo (Deuteronômio 22:10)
• Ninguém deve armazenar Antelopee Barracudadentro do mesmo ibdata1

ATUALIZAÇÃO 2013-07-05 14:26 EDT

Acabei de responder a esta pergunta em ServerFault: Configurando MySQL INNODB Compression KEY_BLOCK_SIZE . Isso me fez olhar para trás em busca de quaisquer perguntas que respondi no DBA StackExchange havia discutido o Barracudaformato e encontrei este meu post antigo. Vou colocar a mesma informação aqui...

De acordo com a documentação do MySQL sobre compressão InnoDB para Barracuda

Compressão e o pool de buffers do InnoDB

Em uma tabela InnoDB compactada, cada página compactada (seja 1K, 2K, 4K ou 8K) corresponde a uma página não compactada de 16K bytes. Para acessar os dados em uma página, o InnoDB lê a página compactada do disco se ela ainda não estiver no buffer pool e, em seguida, descompacta a página em seu formato original de 16K bytes. Esta seção descreve como o InnoDB gerencia o buffer pool em relação às páginas de tabelas compactadas.

Para minimizar a E/S e reduzir a necessidade de descompactar uma página, às vezes o buffer pool contém o formato compactado e não compactado de uma página do banco de dados. Para abrir espaço para outras páginas de banco de dados necessárias, o InnoDB pode “expulsar” do buffer pool uma página não compactada, deixando a página compactada na memória. Ou, se uma página não é acessada há algum tempo, a forma compactada da página pode ser gravada em disco, para liberar espaço para outros dados. Assim, a qualquer momento, o buffer pool pode conter os formulários compactados e descompactados da página, ou apenas o formato compactado da página, ou nenhum.

O InnoDB mantém o controle de quais páginas manter na memória e quais remover usando uma lista LRU, de modo que os dados “quentes” ou acessados ​​com frequência tendem a permanecer na memória. Quando tabelas compactadas são acessadas, o InnoDB usa um algoritmo LRU adaptável para obter um equilíbrio apropriado de páginas compactadas e não compactadas na memória. Esse algoritmo adaptativo é sensível ao fato de o sistema estar sendo executado de maneira vinculada a E/S ou vinculada à CPU. O objetivo é evitar gastar muito tempo de processamento descompactando páginas quando a CPU estiver ocupada e evitar excesso de E/S quando a CPU tiver ciclos sobressalentes que podem ser usados ​​para descompactar páginas compactadas (que podem já estar na memória). Quando o sistema é limitado por E/S, o algoritmo prefere despejar a cópia descompactada de uma página em vez de ambas as cópias, para liberar mais espaço para que outras páginas de disco se tornem residentes na memória. Quando o sistema está vinculado à CPU, o InnoDB prefere despejar tanto a página compactada quanto a descompactada, para que mais memória possa ser usada para páginas “hot” e reduzindo a necessidade de descompactar dados na memória apenas em formato compactado.

Observe que o InnoDB Buffer Pool precisa carregar páginas de dados e páginas de índice lidas para atender às consultas. Ao ler uma tabela e seus índices pela primeira vez, a página compactada deve ser descompactada para 16K. Isso significa que você terá o dobro de conteúdo de dados no buffer pool, a página de dados compactada e não compactada.

Se essa duplicação de conteúdo de dados estiver ocorrendo no Buffer Pool, você precisará aumentar innodb_buffer_pool_size por um pequeno fator linear da nova taxa de compactação. Aqui está como:

CENÁRIO

• Você tem um servidor de banco de dados com um pool de buffers 8G
• Você executou a compressão comkey_block_size=8
  • 8é 50.00%de16
  • 50.00%de 8Gé4G
  • aumentar innodb_buffer_pool_sizepara 12G( 8G+ 4G)
• Você executou a compressão comkey_block_size=4
  • 4é 25.00%de16
  • 25.00%de 8Gé2G
  • aumentar innodb_buffer_pool_sizepara 10G( 8G+ 2G)
• Você executou a compressão comkey_block_size=2
  • 2é 12.50%de16
  • 12.50%de 8Gé1G
  • aumentar innodb_buffer_pool_sizepara 9G( 8G+ 1G)
• Você executou a compressão comkey_block_size=1
  • 1é 06.25%de16
  • 06.25%de 8Gé 0.5G( 512M)
  • aumentar innodb_buffer_pool_sizepara 8704M( 8G( 8192M) + 512M)

MORAL DA HISTÓRIA : O InnoDB Buffer Pool só precisa de mais espaço para respirar ao lidar com dados compactados e páginas de índice.