我有两个用于测试的数据库设置(因此没有活动数据或连接)。
第一个是充当主数据库的MySQL 5.5.57数据库。第二个是充当从站的MySQL 5.7.23数据库。它在MySQL 5.5上运行MySQL,在MySQL 5.7上运行Row Based Replication。
由于某些原因,较大的查询在MySQL 5.7上花费的时间似乎要长得多。例如,我有下表:
CREATE TABLE `test1` (
`col0` int(11) DEFAULT NULL,
`col1` int(11) DEFAULT NULL,
`col2` datetime DEFAULT NULL,
`col3 datetime DEFAULT NULL,
`col4` int(11) DEFAULT NULL,
`col5` int(11) DEFAULT NULL,
`col6` int(11) DEFAULT NULL,
`col7` int(4) DEFAULT NULL,
`col8` int(11) DEFAULT NULL,
`col9` datetime DEFAULT NULL,
`col10` datetime DEFAULT NULL,
`UniqRef` int(10) unsigned NOT NULL AUTO_INCREMENT,
`col11` tinyint(1) unsigned NOT NULL DEFAULT '0',
`col12` tinyint(1) unsigned zerofill DEFAULT NULL,
`col13` tinyint(1) unsigned DEFAULT NULL,
PRIMARY KEY (`UniqRef`),
KEY `col0` (`col0`),
KEY `col3` (`col3`),
KEY `col4` (`col4`),
KEY `col8` (`col8`),
KEY `col5` (`col5`),
KEY `col10` (`Deleted`),
KEY `col2` (`col2`),
KEY `col12` (`col12`) USING BTREE,
KEY `col13` (`col13`)
) ENGINE=InnoDB AUTO_INCREMENT=400046649 DEFAULT CHARSET=latin1;该表大小为21 is,可容纳83261829行(使用count(*))。
如果我运行查询:UPDATE test.test1 SET col9 = NOW() WHERE UniqRef IN ('397958600','397940686','397940704','397940678','397. . . . .
查询包含6945个uniqref条目。它在MySQL 5.5上几乎立即运行,但随后复制到MySQL 5.7,运行时间为90秒。
我已经改变了不同的设置,但到目前为止,它们并没有什么不同:
SET @@global.slave_compressed_protocol = 0;
SET @@global.sync_binlog = 0;
set @@global.range_optimizer_max_mem_size = 0;我还尝试将read_io_threads和write_io_threads更改为各种值,以及更改buffer pool instances的数量,并禁用二进制日志。
还有什么其他的变量可以让我想办法加快速度,而我错过了吗?
2018年UPDATE -10-17
在本地运行时(直接在MySQL 5.7上),通过设置SET @@global.range_optimizer_max_mem_size = 16777216;,我设法加快了查询的速度。在这之后,查询从90+秒转到0秒。
但是,当在MySQL 5.5上运行相同的查询并将其复制到MySQL 5.7时,仍然需要90+秒来运行。
发布于 2018-10-17 13:26:15
我似乎找到了解决办法。简单地说,我将MySQL 5.5设置为也使用基于行的复制,使用以下过程:
SELECT @@GLOBAL.binlog_format;
STOP SLAVE;
FLUSH TABLES WITH READ LOCK;
FLUSH LOGS;
SET GLOBAL binlog_format = 'row';
SET SESSION binlog_format = 'row';
FLUSH LOGS;
UNLOCK TABLES;
START SLAVE;
SELECT @@GLOBAL.binlog_format;在此之后,我在MySQL 5.5上运行了大型查询(立即运行),当它复制到MySQL 5.7时,它也立即运行。
因此,来自MySQL 5.5服务器的基于MySQL 5.7处理语句的复制查询似乎存在一些问题。
。。。但情节更复杂了。尽管MySQL 5.5数据库声称正在使用基于行的复制:
SELECT @@GLOBAL.binlog_format; = ROW
这似乎有助于复制到MySQL 5.7,当我抓取最新的二进制日志(一个小时后或大约10个二进制日志)并对它们运行mysqlbinlog时,我惊讶地发现它们仍然被STATEMENTs填充。只有在数据库完全重新启动之后,二进制日志才开始生成新的基于ROW的格式!!!
https://dba.stackexchange.com/questions/220274
复制相似问题