如何解决我可以在 Aurora MySql 中终止处于“查询结束”状态的进程吗
我在亚马逊的 Aurora 上使用 MySql 5.7 托管了一个大表
两天前，我运行了这个命令：
insert IGNORE into archiveDataNEW
(`DateTime-UNIX`,`pkl_PPLT_00-PIndex`,`DataValue`)
SELECT `DateTime-UNIX`,`DataValue`
FROM offlineData
order by id
limit 600000000,200000000
昨天下午，我的电脑崩溃了，所以与 mysql 的连接被切断了。
昨晚某个时候查询的状态是“查询结束”
今天查询的状态还是“查询结束”
问题： 我可以停止这个过程吗 - 否则只会让事情变得更糟？
当与服务器的连接断开时，MySQL innodb 是否会展开查询？有什么办法让它继续吗？
当它最终完成查询结束过程时，我需要重新运行命令吗？
这是我正在加载数据的表格，任何想法或建议将不胜感激。
CREATE TABLE `archiveDataNEW` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,`DateTime-UNIX` bigint(20) NOT NULL DEFAULT '0',`pkl_PPLT_00-PIndex` int(11) NOT NULL DEFAULT '0',`DataValue` decimal(14,4) NOT NULL DEFAULT '0.0000',PRIMARY KEY (`id`,`DateTime-UNIX`),UNIQUE KEY `Unique2` (`pkl_PPLT_00-PIndex`,`DateTime-UNIX`) USING BTREE,KEY `DateTime` (`DateTime-UNIX`) USING BTREE,KEY `pIndex` (`pkl_PPLT_00-PIndex`) USING BTREE,KEY `DataIndex` (`DataValue`),KEY `pIndex-Data` (`pkl_PPLT_00-PIndex`,`DataValue`) USING BTREE
) ENGINE=InnoDB AUTO_INCREMENT=736142506 DEFAULT CHARSET=utf8
/*!50100 PARTITION BY RANGE (`DateTime-UNIX`)
(PARTITION p2016 VALUES LESS THAN (1483246800) ENGINE = InnoDB,PARTITION p2017 VALUES LESS THAN (1514782800) ENGINE = InnoDB,PARTITION p2018 VALUES LESS THAN (1546318800) ENGINE = InnoDB,PARTITION p2019 VALUES LESS THAN (1577854800) ENGINE = InnoDB,PARTITION p2020 VALUES LESS THAN (1609477200) ENGINE = InnoDB,PARTITION p2021 VALUES LESS THAN (1641013200) ENGINE = InnoDB,PARTITION p2022 VALUES LESS THAN (1672549200) ENGINE = InnoDB,PARTITION p2023 VALUES LESS THAN (1704085200) ENGINE = InnoDB,PARTITION pMAX VALUES LESS THAN MAXVALUE ENGINE = InnoDB) */;```
解决方法
无法完成该语句并提交它插入的行。
这显然是 MySQL 5.7 代码中的一个错误，此处讨论：https://bugs.mysql.com/bug.php?id=91078
症状是查询卡在“查询结束”状态，除了重启 MySQL 服务器，没有办法终止或完成它。但这在 AWS Aurora 上是不可能的，对吗？
该错误日志中有一些关于它是否由查询缓存引起的来回讨论。查询缓存已被弃用，但在 Aurora 中，他们重新启用了它并更改了它的实现。他们确信他们的查询缓存代码解决了 MySQL 的查询缓存实现的缺点，因此他们将其保留在 Aurora 中（这是您应该将 Aurora 视为 MySQL 的一个分支，不一定与 MySQL 本身兼容的众多原因之一）。
,杀死它，如果可以的话。要么忙于提交（这将需要很长时间），要么忙于撤消（这将需要更长的时间）。如果它不会杀死，你就只能等待它了。
更好的方法。
在限制 600000000 和 200000000 中使用 OFFSET 只会在您处理块时变得越来越慢。这是因为它必须跨越 600M 行。
此外，一次 INSERTing 200M 行效率很低。系统必须准备在崩溃的情况下撤消操作。
因此，最好“记住您离开的地方”。或者在像 WHERE id BETWEEN 12345000 AND 12345999 这样的显式块中进行。此外，一次只能处理 1K 行。
但是，你想做什么？
如果您要添加分区，让我们讨论一下是否会有任何好处。看起来您正在添加年度分区。可能唯一的优势是当您需要 DROP PARTITION 摆脱“旧”数据时。任何查询都不太可能运行得更快。
可能的优化：
收缩：
`DateTime-UNIX` bigint(20)
这似乎是一个 unix 时间戳，非常适合 4 字节 INT 或 5 字节 TIMESTAMP；为什么使用 8 字节的 BIGINT？ TIMESTAMP 的优点是允许使用大量日期时间函数。一个 5 字节的 DATETIME 或一个 3 字节的 DATE 将持续到 9999 年年底。我们距 TIMESTAMP 溢出还有 17 年；您知道自 2004 年（今天 - 17 年）以来一直存在的计算机系统是什么？警告：如果您从 TIMESTAMP 切换，将会有需要解决（或忽略）的时区问题。 （如果您需要时间部分，请勿将 DATETIME 拆分为两列；这可能会增加复杂性。）
Drop KEY pIndex (pkl_PPLT_00-PIndex) 使用 BTREE，它与其他两个索引是多余的。
不要预先构建未来的分区；它会损害性能（少量）。在当年年底，用 REORGANIZE 构建下一年的分区。详情请见：http://mysql.rjweb.org/doc.php/partitionmaint
这将通过多种方式提高性能：
PRIMARY KEY (`id`,`DateTime-UNIX`),UNIQUE KEY `Unique2` (`pkl_PPLT_00-PIndex`,`DateTime-UNIX`) USING BTREE,-->
PRIMARY KEY(`pkl_PPLT_00-PIndex`,INDEX(id) -- sufficient for AUTO_INCREMENT
如果在加载表之前不使用非 UNIQUE 索引，它可能会运行得更快。然后执行 ALTER(s) 添加它们。
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 dio@foxmail.com 举报，一经查实，本站将立刻删除。