必须查清数据库、表、列及连接层真实字符集与排序规则，执行SHOW CREATE DATABASE和INFORMATION_SCHEMA.COLUMNS查询确认；存储过程字符串字面量须用_utf8mb4前缀强制解析，变量声明需显式指定CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci，WHERE中避免右侧COLLATE导致索引失效。
查清当前连接和库表的真实字符集与排序规则
隐式转换往往不是代码写错了，而是环境里某一层字符集“悄悄不同”。只看 SHOW VARIABLES LIKE 'character_set%' 不够，它只反映连接层配置；真正起作用的是数据库、表、列三级定义，以及存储过程变量继承的默认规则。
执行这两条命令确认源头：
SHOW CREATE DATABASE your_db_name;
SELECT column_name, character_set_name, collation_name FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = 'your_db_name' AND table_name = 'your_table' AND column_name IN ('target_col');
如果库是 latin1 或表字段用的是 utf8（不是 utf8mb4），而你在过程里拼接或比较时用了 _utf8mb4 字面量，MySQL 就必须做隐式转换——这时就埋下乱码或索引失效的种子。
声明变量和字符串字面量时显式指定字符集
MySQL 存储过程中所有硬编码中文、拼接字符串、IF 判断里的字面量，都必须加 _utf8mb4 前缀。这不是可选项，是防止会话变量干扰的唯一可靠方式。
_utf8mb4 是字符集 introducer，不是函数，不能加括号；它强制该字符串按 utf8mb4 解析，不受 character_set_client 影响。
- 错误写法：
CONCAT('用户不存在', user_id)→ 依赖会话字符集，可能被当latin1解析 - 正确写法：
CONCAT(_utf8mb4'用户不存在', user_id) - 变量声明也要对齐：
DECLARE v_msg VARCHAR(100) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
避免在 WHERE 条件中强制 COLLATE 导致索引失效
这是生产中最隐蔽的性能坑：明明 ref_id 上有索引，但查询却全表扫描。原因往往是 WHERE 右侧用了带 COLLATE 的字面量，而左侧字段实际是 utf8 + utf8_unicode_ci，两者不兼容，MySQL 拒绝复用索引。
比如这句会废掉索引：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
WHERE ref_id = _utf8mb4'abc' COLLATE utf8mb4_unicode_ci
而 ref_id 列真实定义是：
`ref_id` CHAR(36) CHARACTER SET utf8 COLLATE utf8_unicode_ci
解决方案只有两个：
- 统一源头：把字段升级到
utf8mb4+utf8mb4_unicode_ci（推荐） - 临时绕过：去掉右侧
COLLATE，靠_utf8mb4前缀保证字面量解析正确，让 MySQL 自动按列规则做安全比较
动态 SQL 拼接时优先用参数化，而非 CONCAT + 字符串
用 CONCAT 拼接中文变量，本质是把二进制字节流塞进 SQL 字符串，中间经过 character_set_connection 转换，极易丢字节。哪怕你写了 CONVERT(@name USING utf8mb4)，也挡不住某些驱动或中间件的二次转码。
更稳的做法是彻底避开拼接：
- 用
PREPARE stmt FROM 'SELECT * FROM t WHERE name = ?'; EXECUTE stmt USING @name; -
EXECUTE支持二进制安全传参，不走字符集解析路径 - 只有万不得已才拼接，且必须每处中文都加
_utf8mb4前缀
最常被忽略的一点：NAME_CONST() 生成的常量也受当前会话字符集影响，它不是“免死金牌”。如果调用前没执行 SET NAMES utf8mb4，那 NAME_CONST 返回的值照样可能是乱码字节。
