前缀索引需根据数据分布和查询模式选择最短高选择性前缀长度，避免在高重复前缀列无效使用，结合 LEFT 或 LIKE ‘prefix%’ 查询优化，通过对比不同前缀长度的选择性确定最优值。
在 MySQL 中，前缀索引是一种针对字符串列（如 VARCHAR、TEXT）只对前 N 个字符建立索引的策略，主要用于减少索引大小、提升查询性能。但若使用不当，反而会降低查询效率。合理优化前缀索引，能平衡存储开销与查询性能。
选择合适的前缀长度
前缀索引的关键在于选取足够区分数据的最短前缀长度。过短会导致大量重复值，降低选择性；过长则浪费空间，失去前缀索引的意义。
建议方法：
- 计算完整列的选择性：SELECT COUNT(DISTINCT column_name) / COUNT(*) FROM table_name;
- 对比不同前缀长度的选择性：SELECT COUNT(DISTINCT LEFT(column_name, N)) / COUNT(*) FROM table_name;
- 选择接近完整列选择性的最小 N 值。例如，当前缀长度为 8 时选择性已达 0.95 以上，就不必再增加长度。
利用索引选择性评估前缀效果
高选择性意味着索引能更高效地过滤数据。理想前缀应使索引选择性尽量接近原列。
举例：假设有一个 emai l 字段，大多数域名相同（如 xxx@company.com），只需前缀覆盖用户名部分即可有效区分。
可通过以下语句测试：
SELECT COUNT(DISTINCT LEFT(email, 5)) AS prefix_5, COUNT(DISTINCT LEFT(email, 10)) AS prefix_10, COUNT(DISTINCT LEFT(email, 15)) AS prefix_15 FROM users;
观察增长趋势，找到“性价比”最高的长度。
避免在高重复前缀上建索引
如果字段前几位高度相似（如 URL 都以 https:// 开头），前缀索引效果会大打折扣。
此时可考虑：
- 反转字符串后建索引（适用于固定后缀场景）：ALTER TABLE t ADD INDEX idx_rev (REVERSE(url));
- 使用生成列存储反转或截取后的值，并为其建立索引。
- 直接使用全文索引或改用其他索引策略（如哈希索引）。
结合实际查询模式设计
前缀索引仅适用于 LEFT、LIKE ‘prefix%’ 这类前导匹配查询，对 %infix% 无效。
优化建议：
- 分析慢查询日志，确认是否常用前缀匹配查询。
- 确保查询条件中的模式能命中前缀索引，避免隐式失效。
- 对于经常按全值查询的字段，优先考虑全列索引或使用前缀 + 覆盖索引组合。
基本上就这些。前缀索引不是万能方案，关键是根据数据分布和查询需求精细调整，才能真正提升性能。不复杂但容易忽略。
