MySQL 性能优化：前缀索引（Prefix Index）深度解析

在处理包含长字符串字段（如 VARCHAR、TEXT）的表时，直接建立全列索引会导致索引文件极其庞大，增加磁盘 I/O 开销并降低缓存效率。前缀索引 通过截取字段的前 nnn 个字符建立索引，是平衡"存储空间"与"查询性能"的核心技术手段。

---

一、 核心定义与语法

前缀索引是指在创建索引时，仅对字段的前一部分字符建立 B+ 树索引。

示例语法：

-- 为 user 表的 email 字段前 10 个字符创建索引
ALTER TABLE user ADD INDEX idx_email_prefix (email(10));

---

二、 前缀索引的优势

1. 降低索引体积：显著减少索引占用的磁盘空间。
2. 提升写入性能：索引变小后，插入、更新和删除操作（维护索引）所需的物理磁盘操作更少。
3. 提高缓存命中率：更小的索引使得 MySQL Buffer Pool 的一个数据页中能存放更多的索引项，从而减少磁盘寻道次数。

---

三、 如何计算最佳前缀长度

前缀长度 nnn 的选择决定了索引的选择性（Selectivity）。选择性越高，索引过滤重复行的能力越强。理想的前缀索引应当接近全列索引的选择性。

1. 计算步骤

首先计算全列的选择性（基准值）：

SELECT COUNT(DISTINCT email)/COUNT(*) AS total_selectivity FROM user;

然后通过 LEFT 函数测试不同长度的前缀选择性：

SELECT 
    COUNT(DISTINCT LEFT(email, 5))/COUNT(*) AS L5,
    COUNT(DISTINCT LEFT(email, 10))/COUNT(*) AS L10,
    COUNT(DISTINCT LEFT(email, 15))/COUNT(*) AS L15
FROM user;

2. 决策标准

当长度增加到某个临界点后，选择性的提升率会剧烈下降。应选择处于"拐点"处的长度，以确保在空间占用最小的情况下获得足够的过滤性能。

---

四、 物理约束与性能限制

前缀索引虽然节省空间，但会丧失全列索引的部分关键功能。

1. 覆盖索引（Covering Index）失效

由于前缀索引不包含完整的列数据，MySQL 无法仅通过扫描索引来满足查询需求，必须回表读取完整行记录。

• 全列索引查询 ：Extra 字段显示 Using index。
• 前缀索引查询 ：Extra 字段不含 Using index，且必须执行随机 I/O 回表。

2. 排序（ORDER BY）与分组（GROUP BY）失效

MySQL 的执行引擎无法利用前缀索引的逻辑顺序进行排序或聚合，因为索引项并不代表完整数据的真实顺序。

• 示例 ：索引项为 abc，对应完整数据可能是 abcd 和 abcc。在索引中两者位置相同，但在物理排序上 abcc 应在前。
• 结果 ：执行计划会显示 Using filesort。

---

五、 异常场景：区分度极低的前缀

如果字符串的前缀具有高度重复性（例如 URL 均以 https://www. 开头），前缀索引的效果将大打折扣。

优化方案：

1. 倒序存储 ：将字符串反转后再存储并建立前缀索引。例如身份证号，尾部 4 位比前 6 位地区码区分度更高。

   -- 查询示例
   SELECT * FROM user WHERE id_card_reverse = REVERSE('110101...') AND id_card_reverse LIKE REVERSE('...1234')% ;

2. 增加哈希列：新增一个字段存储原字段的 CRC32 或 MD5 校验码，对该哈希列建立索引（等值查询效率极高，但不支持范围查询）。