mysql临时表乱码问题通常是由于字符集设置不正确引起的。1. 临时表的字符集默认继承服务器或数据库的默认字符集，而不是当前会话的character_set_connection或character_set_client；2. 客户端发送的数据为utf8mb4编码，但临时表使用latin1等其他字符集时会导致插入或查询出现乱码或问号；3. 解决方法是在创建临时表时显式指定字符集和排序规则，如使用create temporary table ... default charset=utf8mb4 collate=utf8mb4_unicode_ci；4. 可通过show create table命令确认临时表的字符集配置；5. 更彻底的做法包括在连接后执行set names设置会话字符集，并在mysql配置文件中统一默认字符集和排序规则。只要在创建临时表时指定字符集并确保整个流程中的字符集一致，即可避免大部分乱码问题。
MySQL的乱码问题在开发和运维中经常遇到，尤其是涉及临时表的时候。如果你发现某些会话中查询出来的数据出现乱码，而其他地方又是正常的，很可能是临时表的字符集设置不正确导致的。这个问题虽然不是特别复杂，但如果不了解机制，排查起来还是挺头疼的。
下面我来具体说说怎么处理这个问题。
为什么临时表会影响会话中的乱码？
MySQL的临时表是在当前连接（会话）中创建的，它的字符集默认继承的是服务器或数据库的默认字符集，而不是你当前会话的character_set_connection或者character_set_client。
这就可能导致一个问题：你的客户端传入的数据是UTF8MB4编码，但临时表用的是latin1或其他字符集，结果就是插入或查询时出现乱码或问号。
举个实际的例子：
- 客户端发送SQL语句使用的是utf8mb4
- 数据库默认字符集是utf8mb4
- 但是临时表创建时没有指定字符集，使用了默认的latin1
- 插入中文字符后变成乱码
所以，解决这类问题的关键在于控制临时表的字符集。
如何修改临时表的字符集？
在创建临时表的时候，显式地指定字符集是最直接有效的方式。你可以通过以下方式来实现：
CREATE TEMPORARY TABLE tmp_table (
id INT,
name VARCHAR(100)
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;这样就能确保这个临时表使用的字符集和你的会话、数据库保持一致，避免因字符集不匹配造成的乱码问题。
常见错误操作：
- 忘记加
CHARSET和COLLATE - 使用
utf8而不是utf8mb4，导致无法存储表情符号等4字节字符 - 没有统一整个流程中的字符集配置
怎么确认当前临时表的字符集？
有时候你已经创建了一个临时表，但不确定它到底用了什么字符集。这时候可以用下面这条命令查看：
SHOW CREATE TABLE tmp_table;
输出结果中会有类似这样的信息：
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci |
如果看到的是latin1或者其他非预期的字符集，那说明创建时没有明确指定，需要调整SQL语句重新创建。
更彻底的做法：统一整个会话的字符集配置
除了临时表本身的问题，还需要检查整个会话的字符集是否一致。建议在每次连接后执行以下语句：
SET NAMES 'utf8mb4' COLLATE 'utf8mb4_unicode_ci';
这会一次性设置character_set_client、character_set_connection和character_set_results，保证数据传输过程中的编码一致性。
另外，也可以在MySQL配置文件（如my.cnf或my.ini）中加上：
[client] default-character-set = utf8mb4 [mysqld] character-set-server = utf8mb4 collation-server = utf8mb4_unicode_ci
这样可以减少手动设置的遗漏。
基本上就这些。只要在创建临时表时多加一句字符集声明，再配合会话级别的统一设置，大多数乱码问题都能解决。虽然看起来步骤不多，但在实际项目中，特别是多语言环境或混合使用不同客户端的情况下，这些细节非常容易被忽略。
