本文详解 MySQL 存储过程中因 WHERE 子句中显式指定 COLLATE（尤其是跨字符集/排序规则）导致索引失效、查询变慢的根本原因，并提供可落地的字符集统一策略、索引优化方法及安全编码实践。 本文详解 mysql 存储过程中因 `where` 子句中显式指定 `collate`（尤其是跨字符集/排序规则）导致索引失效、查询变慢的根本原因，并提供可落地的字符集统一策略、索引优化方法及安全编码实践。在 MySQL 5.7 环境下，当存储过程中的 SELECT 查询对字符串列（如 CHAR(36) UUID 类型）使用显式 COLLATE 修饰字面量时，极易触发隐式类型转换与排序规则冲突，进而使本已存在的索引完全失效——这是生产环境中典型的“慢查询隐形杀手”。您遇到的如下语句正是典型表现：SELECT notification_id FROM notification WHERE ref_table = 2 AND ref_id = NAME_CONST('v_wall_detail_id', _utf8mb4'c37e32fc-b3b5-11ec-befc-02447a44a47c' COLLATE 'utf8mb4_unicode_ci');尽管表结构显示 notification 表默认字符集为 utf8mb4，但关键字段 ref_id 的实际定义却源自 utf8 字符集（注意：SHOW CREATE TABLE 中 notification_id 列明确声明 CHARACTER SET utf8），其隐含 collation 很可能是 utf8_general_ci 或 utf8_unicode_ci。而查询中强制使用 _utf8mb4'...' COLLATE utf8mb4_unicode_ci，造成 字符集（utf8 vs utf8mb4）与排序规则（utf8_* vs utf8mb4_*）双重不兼容。? 根本原理：MySQL 索引（B+Tree）依赖列值的确定性排序顺序。当 WHERE 条件右侧的常量使用了与索引列不兼容的字符集或 collation 时，优化器无法保证二者字符串比较的等价性与有序性，被迫放弃索引扫描（Index Range Scan），退化为全表扫描（Full Table Scan）——即使 ref_id 上存在索引，也形同虚设。? 验证与诊断步骤首先确认 ref_id 列的真实字符集与排序规则：SELECT column_name, character_set_name, collation_nameFROM INFORMATION_SCHEMA.COLUMNSWHERE table_schema = 'your_database_name' AND table_name = 'notification' AND column_name = 'ref_id';若返回 character_set_name = 'utf8' 且 collation_name = 'utf8_general_ci'，则上述 utf8mb4_unicode_ci 强制转换必然导致索引失效。?? 核心修复方案：统一字符集与排序规则推荐一步到位：将整张表升级至 utf8mb4 + utf8mb4_unicode_ci（兼顾 Unicode 4 字节支持与国际化排序需求）： Mokker AI AI产品图添加背景