前缀索引无法支持ORDER BY和GROUP BY排序，仅提升等值查询及LIKE 'prefix%'匹配效率；其选择性需通过SQL测算验证，不可经验估算，且联合索引中混用会加剧失效风险。
前缀索引不会提升排序能力，反而可能让 ORDER BY 完全失效；它只影响等值查询和 LIKE 'prefix%' 类前缀匹配的过滤效率，且选择性必须手动验证，不能靠经验估算。
前缀索引对 ORDER BY 和 GROUP BY 没有帮助
MySQL 的 B+ 树索引能支持排序的前提是：索引列完整、有序、且查询条件覆盖了排序所需的最左前缀。前缀索引只存字符串开头若干字节，后续字符被截断，索引树里根本不存在完整值的逻辑顺序。
这意味着：
- 即使你建了
INDEX idx_title (title(15))，SELECT * FROM articles ORDER BY title依然会触发Using filesort -
GROUP BY title同样无法利用该索引做分组加速，因为前缀不唯一，MySQL 无法确认“前15个字符相同”是否意味着整字段相同 - 只有当查询本身也带前缀等值条件（如
WHERE title LIKE 'MySQL%'）且同时ORDER BY title时，优化器才可能用上前缀索引做范围扫描，但排序仍依赖回表后的真实值，索引不参与排序逻辑
索引选择性必须用 SQL 算，不能猜
很多人以为“取前10个字符就够了”，结果发现 SELECT COUNT(DISTINCT LEFT(title, 10)) / COUNT(*) 只有 0.12 —— 这说明 88% 的标题前10位都重复，索引几乎没用。
正确做法是分步测算：
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 先查全列选择性：
SELECT COUNT(DISTINCT title) / COUNT(*) AS selectivity FROM articles - 再试不同长度：
SELECT COUNT(DISTINCT LEFT(title, 20)) / COUNT(*) AS sel_20 FROM articles - 对比
sel_20是否 ≥ 全列选择性的 90%；若不够，继续试 25、30… 直到接近但不过度冗余 - 注意：测试时务必加
WHERE title IS NOT NULL，避免空值干扰基数统计
LIKE 查询能否走前缀索引，只看写法和长度
前缀索引只对形如 WHERE col LIKE 'abc%' 有效，且要求 'abc' 的长度 ≤ 前缀长度。任何含通配符在前（'%abc'）、中间（'ab%c'）或非等值条件（!=、IN）都无法使用。
常见误判点：
-
WHERE title LIKE 'MySQL优化%'→ 能用title(12)索引（'MySQL优化' 长度为 12） -
WHERE title LIKE '%MySQL%'→ 不走任何索引，包括前缀索引 -
WHERE title = 'MySQL优化实战指南'→ 即使建了title(20)，也可能命中，但需回表确认完整值是否一致；若大量重复前缀，会导致回表次数暴增 - utf8mb4 下中文占 3–4 字节，
LEFT(title, 10)实际可能只截了 3 个汉字，别按字符数硬套
联合索引里混用前缀索引要特别小心
比如 ALTER TABLE t ADD INDEX idx_user (name(10), email)，这个索引实际只对 name 做前缀，email 是完整索引。但最左前缀原则仍然生效：
-
WHERE name LIKE 'zhang%' AND email = 'a@b.c'→ 可用 -
WHERE email = 'a@b.c'→ 完全不可用，因为跳过了最左列name -
WHERE name = 'zhangsan'→ 能用，但只靠前10字节匹配，后面字符不参与索引查找，最终靠回表过滤
真正容易被忽略的是：前缀长度一旦定死，就无法在运行时动态调整。上线后发现选择性不足，只能 DROP INDEX 再重建，期间锁表风险得自己扛。
