将 utf8mb4 转换为 latin1 时如何克服性能问题？

如何解决将 utf8mb4 转换为 latin1 时如何克服性能问题？

由于我的无知，我在没有指定排序规则的情况下更改了一些表格。这导致更改后的列（以前为 latin1 个字符）更改为 utf8mb4。

这给运行连接带来了巨大的性能损失。当我说巨大时，我的意思是几分之一秒变成了一个小时或更长时间！

所以我提出了另一个请求，将其转换回 latin1。

问题来了。只有 60k 行的表，一个 utf8mb4 列的 64 个字符需要 10 个小时才能完成。不，这不是错误。十个小时。而我更大的问题是，我还有其他有数百万行的表，从今天起的几年内都会给我 ETA！

现在，我想知道我的选择是什么，因为我无法承受让这些表只读超过一天的时间。

我知道 MysqL ALTER 创建了一个表的副本。这是有道理的，因为这是字段大小的变化，所以我怀疑我是否可以选择使用 ALGORITHM=INPLACE。

如果我不能做 INPLACE 那么我就不能使用 LOCK=NONE 选项。

到底为什么utf8mb4 -> latin1 转换会产生如此大的影响？

请注意，转换后的列已编入索引，这可能是造成影响的原因！

任何建议或链接将不胜感激！也许解决方案是删除索引（以避免索引转换中的时髦多字节问题）进行快速更改，然后添加索引？

预先感谢您提出的任何严肃建议，我怀疑由于它的独特性，我可能找不到太多帮助。

编辑

 jobs | CREATE TABLE `jobs` (
  `auto_inc_key` int(11) NOT NULL AUTO_INCREMENT,`request_entered_timestamp` datetime NOT NULL,`hash_id` char(64) CHaraCTER SET latin1 NOT NULL,`name` varchar(128) CHaraCTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,`host` char(20) CHaraCTER SET latin1 NOT NULL,`user_id` int(11) NOT NULL,`start_date` datetime NOT NULL,`end_date` datetime NOT NULL,`state` char(12) CHaraCTER SET latin1 NOT NULL,`location` varchar(50) NOT NULL,`value` int(10) NOT NULL DEFAULT '0',`aggregation_job_id` char(64) CHaraCTER SET latin1 DEFAULT NULL,`aggregation_job_order` int(11) DEFAULT NULL,PRIMARY KEY (`auto_inc_key`),KEY `host` (`host`),KEY `hash_id` (`hash_id`),KEY `user_id` (`user_id`,`request_entered_timestamp`),KEY `request_entered_timestamp_idx` (`request_entered_timestamp`)
) ENGINE=InnoDB AUTO_INCREMENT=9068466 DEFAULT CHARSET=utf8mb4

 jobs_archive | CREATE TABLE `jobs_archive` (
  `auto_inc_key` int(11) NOT NULL AUTO_INCREMENT,`value` int(11) NOT NULL DEFAULT '0',`request_entered_timestamp`)
) ENGINE=InnoDB AUTO_INCREMENT=239432 DEFAULT CHARSET=utf8mb4

(taken from PROCEDURE,but you catch the drift...)
INSERT INTO jobs_archive (SELECT * FROM jobs WHERE (TIMESTAMPDIFF(DAY,request_entered_timestamp,starttime) > days));