LIKE '%xxx'一定不走索引，因B+树依赖前缀可确定性，无法定位扫描起点，只能全表扫描；复合索引、正则、函数包裹均无效，唯一解是全文索引或外部搜索引擎。
LIKE '%xxx' 为什么一定不走索引
因为 B+ 树索引的结构决定了它只能高效支持“从左开始”的匹配。索引项是按字段完整值字典序排序的，WHERE name LIKE '%john' 没有确定的前缀，MySQL 无法预判哪些索引节点可能包含 john，只能逐行扫描——这不是优化器“放弃”，而是根本没得选。
优化器真会主动放弃索引吗？什么情况下会
会，但仅限于成本评估后认为全表扫描更便宜。比如 WHERE name LIKE 'john%' 明明能走索引，但如果查询返回 30% 的行，优化器可能判定：走索引 + 大量回表（随机 IO）不如直接全表扫描（顺序 IO）。这和通配符位置无关，而是由 rows 和 filtered 估算值驱动的。
- 用
EXPLAIN看type字段：出现ALL是全表扫描，range或ref才算走了索引 - 检查
key字段是否为NULL：是则确认索引未被选用 -
Extra出现Using where不代表用了索引，只是表示 WHERE 条件在 Server 层做了过滤
字符集和排序规则不一致也会让索引“假装失效”
即使写成 WHERE name LIKE '张%'，也可能不走索引，原因常藏在字符集隐式转换里：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 表列用
utf8mb4，但客户端连接用latin1→ MySQL 自动把索引列转成latin1再比对，等价于在列上用了函数，索引失效 - 排序规则是
utf8mb4_general_ci，而查询含繁体字“張”，简繁归并逻辑可能导致索引分支跳转失败 - 建表没显式指定
COLLATE，依赖服务器默认值 → 开发/测试/生产环境行为不一致
验证方法：SHOW CREATE TABLE users; 看列定义；再跑 SHOW VARIABLES LIKE 'character_set%'; 和 SHOW VARIABLES LIKE 'collation%';，确保 client、connection、results 三者一致。
REVERSE() 函数索引真能救后缀查询吗
不能。MySQL 8.0+ 虽支持函数索引，但 CREATE INDEX idx_name_rev ON users ((REVERSE(name))); 配合 WHERE REVERSE(name) LIKE REVERSE('john') || '%'，本质仍是全索引扫描——因为 REVERSE() 打乱了原始字典序，索引失去范围查找能力，优化器只能线性遍历。
真正可行的替代方案只有两个：用 FULLTEXT 索引处理中文分词场景，或把模糊搜索逻辑下沉到 Elasticsearch 这类专用引擎。硬靠 B+ 树扛后缀匹配，是架构设计层面的误判。
