MYSQL 5.7 升级 8.0 后的 由于字符集导致的大问题 ？

开头还是介绍一下群，如果感兴趣polardb ,mongodb ,mysql ,postgresql ,redis 等有问题，有需求都可以加群群内有各大数据库行业大咖，CTO，可以解决你的问题。加群请联系 liuaustin3 ，在新加的朋友会分到2群。

MYSQL 8.0 已经很多年了，但是，但是，但是，还有很多公司和业务项目在MYSQL5.6 ,5.7上继续奋斗，这还不是一个重要的问题，重要的问题是早期在MYSQL 5.7 上的一些基础，并未进行改变后到了MYSQL 8 上的使用一段时间产生的问题。

这里在MYSQL5.6,MYSQL.5.7上大部分的表还都是 utf8 ， default charset =utf8  而在这些数据库升级的情况下，表基本上是照搬到MYSQL 8.0上的，但是后续会产生一个问题。建立新的表。此次我们采用MYSQL 最新的版本之一，MYSQL 8.030 来进行相关的问题的分析和查找。

下面就是一个典型的例子，在创建一个MYSQL的表的情况下，如果开发部指定 default charset=utf8 则默认建立新表就是utf8mb4 ,而这样就会产生一个严重的问题。

一个数据库中的表的字符集不一致。然后就会产生一个问题，两个表的字符集不同，如果两个表之间的查询是不关联的，这到不会造成什么严重的问题，而如果这两个表产生了之间的关联性那么问题就出现了。

我们创造一个奇怪的数据库，以及表，这里的表的字符集在 utf8  和  utf8mb4 之间混合着。

在这样的情况下，会产生如下一些假设,下面是一些表的表结构，其中orders的表，是UTF8MB4 格式 排序是 utf8mb4_9000_ai_ci  ，而我们的payments表是utf8mb3 的格式。

CREATE TABLE `orders` (

  `ordernumber` varchar(200) CHARACTER SET utf8 NOT NULL,

  `orderDate` date NOT NULL,

  `requiredDate` date NOT NULL,

  `shippedDate` date DEFAULT NULL,

  `status` varchar(15) CHARACTER SET utf8 NOT NULL,

  `comments` text CHARACTER SET utf8,

  `customernumber` varchar(200) CHARACTER SET utf8 DEFAULT NULL,

  PRIMARY KEY (`ordernumber`),

  KEY `customerNumber` (`customernumber`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci；

 CREATE TABLE `payments` (

  `customerNumber` varchar(200) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL,

  `checkNumber` varchar(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_0900_ai_ci NOT NULL,

  `paymentDate` date NOT NULL,

  `amount` decimal(10,2) NOT NULL,

  PRIMARY KEY (`customerNumber`,`checkNumber`),

  KEY `idx_payment` (`paymentDate`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8mb3；

1   使用 left join 的时候，两个表，谁在前谁在后，优化器是否能正确运行相关结果。

explain select *

from payments as p 

left join (select * from orders) as o on p.customerNumber = o.customerNumber 

where paymentdate > '2005-01-01';

explain select *

from orders as o 

left join (select * from payments) as p on p.customerNumber = o.customerNumber 

where paymentdate > '2005-01-01';

语句如上，第一个语句为 utf8 作为驱动表，可以明显看到因为两个表的字符集和collation的不同，导致无法走索引进行查询，这里也就是 payments  的主键与order 的主键无法进行正确的连接和比对，而数据库没有办法，走了另外的优化方式，通过HASH JOIN 的方式进行处理。 

那么我们如果反过来进行查询的话情况是不是有变化，有些文章中提到变换驱动表关系，可以在有些版本上可以解决由于字符集不同的问题，导致的索引失效的问题。

那么我们变换一下驱动表的位置，整体的查询计划进行了变化，相关的执行计划的效率稍有提高。

我们将语句实际执行，并查看profilings ，这里可以看到的是，我们将payments 放到上面的情况下 executing  为 700 而将ORDER 放到驱动表的情况下，execute 变为 1742 

因为怕测试中的一些查询与表的行数等特征影响，我们在变化一下两个表的coding .

mysql> ALTER TABLE orders CONVERT TO CHARACTER SET utf8;

Query OK, 0 rows affected, 1 warning (0.01 sec)

Records: 0  Duplicates: 0  Warnings: 1

mysql> 

mysql> 

mysql> ALTER TABLE payments CONVERT TO CHARACTER SET utf8mb4;

Query OK, 0 rows affected (0.01 sec)

Records: 0  Duplicates: 0  Warnings: 0

这里我们再次做相关的测试，发现调整后，

我看可以看到，实际上经过以上的操作和分析，如果作为驱动表，表小并且是utf8mb4的情况下，要比驱动表大并且是 utf8 的情况略好。

但如何，都不如统一的字符集让数据库的查询更能良好的运行。在我们统一字符到 utf8mb4 后，整体的查询正常了

所以以上列子中，主要是说明在MYSQL 5.7 迁移过来的表大部分都是 UTF8MB3 ，而如果MYSQL 8 不做任何处理，则新建的表是 UTF8MB4 ，所以，希望MYSQL 的同学注意以上问题，注意这样的情况，尽量避免。

另外还有一些事情，需要深入，有的时候即使字符集不同，collation的排序在某些情况下，在字符集不同的情况下还可以走索引。