collate强制转换引发索引失效，因字符集不一致导致mysql无法复用b+tree索引；须确保where条件左右字符集相同，否则触发隐式转换和全表扫描。
存储过程中 COLLATE 强制转换为什么反而引发索引失效
直接在 WHERE 条件里对字面量加 COLLATE（比如 _utf8mb4'xxx' COLLATE utf8mb4_unicode_ci），看似“统一了规则”，实则常导致 MySQL 放弃使用索引。根本原因是：左侧字段（如 ref_id）定义为 utf8 + utf8_general_ci，右侧却用 utf8mb4 字符集 + utf8mb4_unicode_ci 排序规则——字符集不一致时，MySQL 无法安全复用索引的 B+Tree 比较逻辑。
这种写法常见于存储过程里用 NAME_CONST() 传参的场景，比如：
SELECT notification_id FROM notification WHERE ref_id = NAME_CONST('v_id', _utf8mb4'abc' COLLATE utf8mb4_unicode_ci);
只要 ref_id 列不是 utf8mb4，这条语句就大概率触发全表扫描。
验证 ref_id 列真实排序规则的三步命令
别信 SHOW CREATE TABLE 的默认值，得查 INFORMATION_SCHEMA 里的实际定义：
- 运行
SELECT column_name, character_set_name, collation_name FROM INFORMATION_SCHEMA.COLUMNS WHERE table_schema = 'your_db' AND table_name = 'notification' AND column_name = 'ref_id'; - 若返回
character_set_name = 'utf8'，哪怕库默认是utf8mb4，也说明该列没升级过 - 此时任何对等值条件右侧显式指定
utf8mb4_*的COLLATE，都会触发隐式转换
COLLATE 强制转换的两种可用但受限的场景
COLLATE 不是不能用，而是必须满足“同字符集前提”才安全：
- 当左右两边都是
utf8mb4字符集时，用COLLATE utf8mb4_0900_ai_ci做大小写/重音控制是可行的，例如临时需要忽略重音匹配：WHERE name COLLATE utf8mb4_0900_as_cs = 'café' - 跨表 JOIN 时，若两表字段字符集一致但排序规则不同（如
utf8mb4_unicode_civsutf8mb4_0900_ai_ci），可在 ON 条件中对其中一侧加COLLATE对齐，但仅限调试或临时修复 - 生产存储过程里长期依赖
COLLATE对齐，等于把字符集治理问题往后拖——下次换一个字段、换一个库，又得改一遍
真正该做的：停用 COLLATE 修复，转向结构层统一
靠 COLLATE 打补丁，本质是掩盖底层不一致。真正省心的做法是让字段自己“长成一样”：
- 先确认目标排序规则，MySQL 8.0 推荐
utf8mb4_0900_ai_ci，5.7 可选utf8mb4_unicode_ci - 执行
ALTER TABLE notification MODIFY ref_id CHAR(36) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;（注意保留原长度和约束） - 修改后，存储过程里所有
NAME_CONST()或变量赋值，直接用_utf8mb4'xxx'即可，无需再写COLLATE - 如果表有外键或触发器，记得检查它们是否依赖旧字符集——有些触发器体内的字符串字面量也会隐式触发转换
最易被忽略的一点：即使你改完了表结构，information_schema 里查到的 collation_name 是对的，但如果存储过程中用了预编译的游标或缓存的执行计划，仍可能沿用旧路径。建议修改后执行 FLUSH TABLES 或重启存储过程上下文。
