17370845950

LIKE模糊查询易致索引失效，因前置通配符破坏B+树有序查找；仅LIKE 'abc%'等后缀匹配且满足最左前缀、类型一致、无函数包裹时才可能走索引；中文场景需统一字符集与校对规则，复杂需求应优先选用全文索引或专用搜索引擎。

SQL中LIKE模糊查询容易导致索引失效，根本原因在于匹配模式破坏了B+树索引的有序查找路径。只有当通配符不前置、且符合最左前缀原则时，索引才可能被有效利用。

LIKE以%开头必然全表扫描

当WHERE条件为LIKE '%abc'或LIKE '%abc%'时，数据库无法利用索引的有序性定位起始位置，只能逐行比对，索引完全失效。这是最常见的性能陷阱。

• 避免在业务逻辑中依赖前导%的模糊搜索
• 如必须支持“包含”语义，可考虑倒序存储字段+反向查询（如：存储reverse(title)，查LIKE 'cba%'）
• 或改用全文索引（MySQL的FULLTEXT、PostgreSQL的tsvector）替代普通B+树索引

LIKE 'abc%'能走索引，但有前提

只有LIKE 'abc%'这类后缀通配才可能命中索引，前提是：

• 该字段是复合索引的最左列（例如索引为(name, status)，则name LIKE 'abc%'可用，但status LIKE 'x%'不可用）
• 字段类型与查询值类型一致（如字符集、collation相同），否则隐式转换会导致索引失效
• 未对字段使用函数（如UPPER(name) LIKE 'ABC%'会跳过索引）

中文模糊搜索更需谨慎

中文字段常因排序规则（collation）和字符集（如utf8mb4_unicode_ci）影响索引行为。即使写成name LIKE '张%'，若字段定义为utf8mb4_bin而连接使用utf8mb4_general_ci，也可能触发隐式转换。

• 统一客户端、连接、字段三者的字符集与校对规则
• 对高频中文前缀搜索，可额外建生成列索引（MySQL 5.7+）：ALTER TABLE user ADD name_prefix VARCHAR(10) STORED AS (LEFT(name,10)); CREATE INDEX idx_name_prefix ON user(name_prefix);
• 避免直接LIKE '%张%'，优先拆解为“首字+其他条件”组合过滤

替代方案比硬扛LIKE更高效

当模糊需求复杂时，应跳出LIKE思维，选用更适合的技术：

• 前缀搜索 → 使用前缀索引（INDEX(name(10))）或覆盖索引优化
• 关键词检索 → 引入Elasticsearch、Meilisearch等专用搜索引擎
• 拼写容错/近似匹配 → 使用Levenshtein距离函数（配合函数索引）或pg_trgm扩展（PostgreSQL）
• 用户输入联想 → 前端缓存常用词+后端用Trie树或Redis Sorted Set预热高频前缀