那些遇到过的问题

innodb_file_format 梭子鱼

atx*_*dba 31 mysql innodb mysql-5.5

我有几个问题要问那些更熟悉的人。尽管支持 Barracuda，但我的大多数实例都在运行 Antelope。

我正在寻找一些压缩 innodb 表的方法。我的理解是这仅在 Barracuda 格式下可用。

  1. 我看到 innodb_file_format 是动态的，所以我可以在没有反弹的情况下切换。我应该知道这样做是否有任何影响。我只能说这意味着将使用该格式创建新表或随后更改的表。这一切都正确吗？
  2. 我希望不必经过并转换我所有的表。在同一个表空间中共存羚羊表和梭鱼表是否符合犹太教规？即使它有效，是否有任何问题需要注意？

从我读过的和从我的测试中收集到的答案是：是的。是的。我不知道。

更新

自从这篇文章以来，我一直在各种情况下运行一些动态表和一些压缩表，没有出现问题。此外，我 当时忽略了阅读http://dev.mysql.com/doc/refman/5.5/en/innodb-file-format-identifying.html。

启用给定的 innodb_file_format 后，此更改仅适用于新创建的表而不是现有的表。如果您确实创建了一个新表，则包含该表的表空间将使用该表功能所需的“最早”或“最简单”文件格式进行标记。例如，如果您启用文件格式 Barracuda，并创建一个未压缩且不使用 ROW_FORMAT=DYNAMIC 的新表，则包含该表的新表空间将被标记为使用文件格式 Antelope。

因此，即使您允许 Barracuda，表也将创建为 Antelope。混合是不可避免的，除非您将每个表指定为 row_format 动态或压缩表。

没有迹象表明您应该在引入第一个 Barracuda 表时进行完整的转储和重新加载（例如在升级 mysql 的主要版本时推荐）

Mor*_*ker 25

所以我晚了将近 4 年才回答这个问题：

  • InnoDB 文件格式是在 InnoDB 独立于 MySQL 服务器的时候构思出来的（例如：MySQL 5.1 可以运行两个不同版本的 InnoDB）。

  • 您不想运行 Barracuda（在 2012 年）的原因是它会降低降级 MySQL 的灵活性（即在升级失败后，您想移回无法读取较新格式的版本）。即不应该有为什么羚羊更好的技术原因。

  • 在 MySQL 5.7 中，该innodb_file_format选项已被弃用。由于 MySQL 和 InnoDB 不再独立，因此 InnoDB 可以使用 MySQL 的升级规则以及需要什么向后兼容。无需混乱的设置！

  • 在 MySQL 5.7 中，默认切换到Barracuda/DYNAMIC. 由于所有当前支持的 MySQL 版本都可以读取这种格式，因此远离 Antelope 并仍然提供降级是安全的。

  • 在 MySQL 5.7 服务器上，Antelope 表将Barracuda/DYNAMIC在下一次表重建（优化表等）时升级到。也就是说，除非它们是专门用ROW_FORMAT=oldrowformat.

  • 在 MySQL 8.0 中，innodb_file_format删除了该选项。

MySQL 5.7 还引入了选项innodb_default_row_format，默认为 DYNAMIC。这解决了更新中的要点。

Gop*_*ath 11 

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)
Run Code Online (Sandbox Code Playgroud)

Rol*_*DBA 9

如果您真的想使用 Barracuda 格式玩 InnoDB，您应该将所有内容 mysqldump 到 /root/MySQLData.sql 之类的内容。这使得数据文件格式独立。

使用另一个带有新 ibdata1 和 innodb_file_per_table 的 MySQL 实例（可选，我个人偏好）。将文件格式更改为 ibdata1 为空。然后，重新加载 /root/MySQLData.sql 并处理数据。

我听说过一些关于 PostgreSQL 必须调整设置才能使 8.2.4 数据库与 9.0.1 二进制文件一起工作的轻微恐怖故事。如果我们尝试使两种文件格式驻留在同一个系统表空间 (ibdata1) 和/或.ibd文件中（如果我们知道此类设置），则同样的情况可能适用。

就犹太洁食而言...

  • 任何人都不应将肉类和奶制品存放在同一个冰箱中
  • 任何人都不应将牛和驴放在同一个轭下（申命记 22:10）
  • 没有人应该将Antelope和存储Barracuda在同一个 ibdata1 中

更新 2013-07-05 14:26 EDT

我刚刚在 ServerFault 中回答了这个问题：设置 MySQL INNODB 压缩 KEY_BLOCK_SIZE。这让我回想起我在 DBA StackExchange 中讨论过的Barracuda格式中回答的任何问题，我发现了我的这篇旧帖子。我将在这里放置相同的信息...

根据用于 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增加新压缩率的一个小的线性因子。方法如下：

设想

  • 您有一个带 8G 缓冲池的数据库服务器
  • 你运行压缩 key_block_size=8
    • 8是50.00%的16
    • 50.00%的8GIS4G
    • 提高innodb_buffer_pool_size到12G( 8G+ 4G)
  • 你运行压缩 key_block_size=4
    • 4是25.00%的16
    • 25.00%的8GIS2G
    • 提高innodb_buffer_pool_size到10G( 8G+ 2G)
  • 你运行压缩 key_block_size=2
    • 2是12.50%的16
    • 12.50%的8GIS1G
    • 提高innodb_buffer_pool_size到9G( 8G+ 1G)
  • 你运行压缩 key_block_size=1
    • 1是06.25%的16
    • 06.25%的8GIS 0.5G（512M）
    • 提高innodb_buffer_pool_size到8704M( 8G( 8192M) + 512M)

故事寓意：InnoDB 缓冲池在处理压缩数据和索引页时只需要额外的喘息空间。

归档时间：

查看次数：

56419 次

最近记录：

7 年，4 月 前
相关归档
如何在 MySQL 5.5 中轻松地将 utf8 表转换为 utf8mb4 110
这是一组正常的 MySQL 权限吗？ 9
通过 MySQL 在半径中获取 zip 的问题 9
MySQL：如何减少 unsigned int 列？ 8
MySQL 的 CPU 使用率高，根本没有运行任何查询 7
mysql：内连接需要 3 分钟 5
等价于其他数据库中的`ora_rowscn`？ 5
MySQL 如何管理其与索引相关的内存？ 5
MySQL v5.7 自动关闭 5
重启时的 Mysql 内部 1
难疑归档
存储与计算聚合值 104
写 varchar 和 nvarchar 之间的区别 65
移动数据库（备份，恢复）后，我必须重新添加用户 52
使用 WHERE IN 删除操作期间的意外扫描 40
收缩数据库和文件有什么区别？ 37
更改表检查约束 31
删除/插入时同一独占锁定集群键（使用 NHibernate）上的 SQL 死锁 30
如何存储时间序列数据 25
在 INSERT 语句的 OUTPUT INTO 子句中使用源列 (SQL Server) 24
如何强制一个记录为布尔列的值为真，而所有其他记录为假值？ 23