【问题标题】:mysql innodb table with inconsistent row_formatmysql innodb 表的 row_format 不一致
【发布时间】:2018-10-25 07:47:41
【问题描述】:

我对 MySQL (5.5.59) 有一个奇怪的问题:

我有一个日志数据库(我存储供应商请求的原始数据)。此表已压缩:

CREATE TABLE `logs` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `idLogType` tinyint(3) unsigned NOT NULL,
  `idAccount` mediumint(8) unsigned NOT NULL,
  (...)
  `message` text NOT NULL,
  `date` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `LOGTYPE` (`idLogType`),
  KEY `ACCOUNT` (`idAccount`),
) ENGINE=InnoDB AUTO_INCREMENT=(...) DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8

我的目标是通过删除旧记录并重建表来清理此表。由于它是一张大桌子,我使用了 pt-online-schema-change 和 Oak-chunk-update 来完成这项工作。

我用https://shlomi-noach.github.io/openarkkit/oak-chunk-update.html删除了所有去年的旧记录

然后我执行表的重建以释放可用空间(innodb_file_per_table 已启用

pt-online-schema-change 
    --alter "ENGINE=InnoDB" 
    --nocheck-replication-filters --execute --statistics --progress=percentage,1 
    --set-vars='lock_wait_timeout=60' --check-alter 
    --no-swap-tables --no-drop-triggers --no-drop-old-table --no-drop-new-table 
    --chunk-time=1 --chunk-size=20 --new-table-name='__new_logs'         
    h=**HOST_#########**,D=DB_#########,t=logs,u=root --ask-pass

(重点是 --alter 语句)

所以现在,我有 2 张桌子:

  • 日志(原版)
  • __new_logs 新日志(优化)

但它们在结构上并不相同:

SELECT TABLE_NAME, ENGINE, ROW_FORMAT, CREATE_OPTIONS
FROM information_schema.tables  
WHERE 
    ENGINE = 'innodb' AND TABLE_NAME LIKE '%logs'

返回这个结果:

'TABLE_NAME'         'ENGINE'         'ROW_FORMAT'         'CREATE_OPTIONS',
'__new_logs'         'InnoDB'         'Compact'         'row_format=COMPRESSED KEY_BLOCK_SIZE=8',
'logs'         'InnoDB'         'Compressed'         'row_format=COMPRESSED KEY_BLOCK_SIZE=8',

为什么表 __new_logs 被标记为“紧凑”且未压缩,但仍将“创建选项”设置为 row_format=COMPRESSED KEY_BLOCK_SIZE=8

__new_logs 表的 show create table 显示:

CREATE TABLE `__new_logs` (
  `id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  `idLogType` tinyint(3) unsigned NOT NULL,
  `idAccount` mediumint(8) unsigned NOT NULL,
  (...)
  `message` text NOT NULL,
  `date` datetime NOT NULL,
  PRIMARY KEY (`id`),
  KEY `LOGTYPE` (`idLogType`),
  KEY `ACCOUNT` (`idAccount`),
) ENGINE=InnoDB AUTO_INCREMENT=(...) DEFAULT CHARSET=utf8 ROW_FORMAT=COMPRESSED KEY_BLOCK_SIZE=8

所以它仍然被标记为压缩。

最后一件奇怪的事,__new_logs 表比原来的 logs 表要大...我感觉这个新表并没有真正进行压缩...

【问题讨论】:

  • 下次请考虑mysql.rjweb.org/doc.php/deletebig中讨论的选项
  • 这是一个压缩问题(不是删除大量行)。并且我使用了链接中描述的一种方法(即,oak-chunk-update 按块删除记录)

标签: mysql compression innodb information-schema pt-online-schema-change


【解决方案1】:

我想我找到了解决方案...

https://www.percona.com/blog/2014/01/14/innodb-file-formats-here-is-one-pitfall-to-avoid/

SHOW VARIABLES LIKE 'innodb_file_format'

=> 羚羊。

压缩仅适用于梭子鱼。

所以我的表日志已经被压缩了,肯定是用innodb_file_format=Barracuda压缩的,但是变量肯定被还原为Antelope...

我需要重新创建表格...但这次使用了良好的文件格式。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2014-06-26
    • 2021-10-31
    • 2014-08-10
    • 1970-01-01
    • 2019-10-03
    • 2014-04-06
    • 1970-01-01
    • 2013-07-02
    相关资源
    最近更新 更多