带国际前缀的手机号查询优化：索引失效与字段拆分方案咨询

关于模糊查询导致索引失效的问题 #

对的，phone like '%12345678910'这种后缀匹配的模糊查询会直接让Phone字段的索引失效。因为B-tree索引是按字段值的前缀顺序存储的，当查询条件以通配符%开头时，数据库无法利用索引的有序性快速定位匹配项，只能执行全表扫描，查询效率会大幅下降。

新增前缀字段的方案可行性 #

这个方案完全可行，且是推荐的结构化处理方式，具体实施要点如下：

• 拆分字段：新增CountryCode字段存储国际前缀（如+86），将原Phone字段调整为LocalPhone（仅存11位数字），同时给LocalPhone创建索引。
• 数据迁移：将现有Person表中Phone字段的11位数字直接存入LocalPhone，CountryCode可设置默认值（如+86），确保历史数据正常查询。
• 业务适配：后续新增或更新手机号时，通过业务逻辑将前缀和本地号码拆分，分别存入对应字段；查询时直接用LocalPhone = '12345678910'，完全不影响索引使用，效率和之前的等值查询一致。

其他可选方案 #

如果不想改动表结构，也可以尝试两种替代方式：

• 反向索引：给REVERSE(Phone)创建索引，查询时改写为REVERSE(Phone) LIKE CONCAT(REVERSE('12345678910'), '%')，利用反向后的前缀匹配命中索引，但这种方式可读性差，维护成本高。
• 计算字段索引：若使用的数据库支持（如MySQL生成列、SQL Server计算列），可新增持久化计算字段LocalPhone AS RIGHT(Phone, 11)并创建索引，查询时直接用LocalPhone = '12345678910'，无需手动维护数据，但要注意不同数据库对计算字段索引的支持差异。

内容的提问来源于stack exchange，提问作者Zhang