配置规范的MySQL是否会返回无效UTF-8？读写有效性疑问

这是个相当关键的问题，涉及到MySQL字符集处理的核心逻辑，我来逐一拆解你的疑问：

1. 客户端用utf8mb4连接，是否可能查到包含无效UTF-8字节序列的数据？ #

是的，完全有可能。最常见的场景是数据库中存在遗留数据：比如之前该列使用的是latin1或其他单字节字符集，后来被修改为utf8mb4，但原有数据并没有做正确的字符集转换。这些旧数据的字节序列在latin1下是合法的，但在utf8mb4视角下就是无效的UTF-8。当你用utf8mb4连接查询时，MySQL会直接返回这些原始字节，客户端拿到的自然就是无效的UTF-8序列。

另外，如果数据是通过二进制写入方式（比如用_binary前缀强制插入字节流）或者某些绕过字符校验的工具导入的，也会导致列中存储无效字节，查询时自然会被返回。

2. 是否存在向utf8mb4列插入非有效UTF-8数据的情况？ #

是的，有几种典型场景：

• 关闭严格SQL模式：当sql_mode没有包含STRICT_TRANS_TABLES或STRICT_ALL_TABLES时，MySQL不会因为无效UTF-8字节报错，而是会自动将无效字节替换成�（Unicode替换字符）。虽然最终存储的是合法字符，但如果你的应用逻辑期望原始字节，这相当于间接“插入”了非预期数据；
• 使用INSERT IGNORE或REPLACE：即使开启了严格模式，这两个语句会忽略插入时的字符校验错误，同样将无效字节替换成�后存储；
• 特殊导入工具/方式：比如使用LOAD DATA INFILE时，如果没有指定正确的字符集参数，或者源文件本身包含无效UTF-8字节，且工具没有做校验，可能会直接将这些字节写入列中（取决于具体参数配置）；
• 驱动或应用层绕过：某些应用程序驱动可能在发送数据时没有做UTF-8校验，直接将无效字节发送给MySQL，如果MySQL的校验机制被绕过（比如极特殊的配置），也可能导致无效字节被存储。

3. 通过utf8mb4连接查询非二进制列，是否可以合理认为返回的数据始终是有效的UTF-8？ #

不能绝对保证。只有当你的数据库满足以下所有条件时，才能放心认为返回的是有效UTF-8：

• 所有数据都是在严格SQL模式下，通过utf8mb4连接合规插入的；
• 没有遗留的非utf8mb4字符集转换过来的数据；
• 没有通过二进制工具、忽略错误的语句插入过无效字节。

如果以上任何一条不满足，查询返回的数据中就可能包含无效的UTF-8字节序列。

内容的提问来源于stack exchange，提问作者deceze