SHOW CREATE TABLE，看看它是否真的设置了 columns 上的CHARACTER SET和COLLATION，而不仅仅是默认值。
CHARACTER SET * 在ALTERs之前 * 是什么？
对 * 应该 * 包含utf8的字段执行SELECT col, HEX(col) ...。这将帮助我们确定表中是否真的包含utf8。字符的 * 编码 * 根据CHARACTER SET而不同; X1 M7 N1 X有助于发现这种情况。

• 排序 *（WHERE、ORDER BY等）由COLLATION控制。索引可能必须基于您的ALTER TABLE重新构建。带索引的大型表是否需要“很长”时间来转换？

要真正了解utf8_general_ci和utf8_unicode_ci之间的区别，您需要一个“组合重音”，或者更简单地说，德语ß与ss：

mysql> SELECT 'ß' = 'ss' COLLATE utf8_general_ci,
              'ß' = 'ss' COLLATE utf8_unicode_ci;
+-------------------------------------+-------------------------------------+
| 'ß' = 'ss' COLLATE utf8_general_ci  | 'ß' = 'ss' COLLATE utf8_unicode_ci  |
+-------------------------------------+-------------------------------------+
|                                   0 |                                   1 |
+-------------------------------------+-------------------------------------+

但是，要在表中测试它，需要存储这些值，并使用WHERE或GROUP_CONCAT或其他方法来确定是否相等。
您有什么“证据”证明ALTERs未能实现排序规则更改？
（回应其他意见：REPAIR应该是无关的。CONVERT TO告诉ALTER实际修改数据，因此它应该已经完成了所需的操作。）

你必须改变每个表中每个字段的排序规则，就像你说的，表的排序规则只是后来创建的字段的默认值，数据库的排序规则只是后来创建的表的默认值。

正如Lorenz Meyer所说，表的排序规则只是以后创建的字段的默认值，您还需要显式地设置列的默认值。
这样的变化看起来像：

ALTER TABLE mytable CHANGE mycolumn mycolumn varchar(15) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci