【发布时间】: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