LIKE仅适用于简单模式匹配，不支持全文检索功能；其通配符%匹配任意长度字符、_匹配单个字符，但无法利用索引加速%开头或中间匹配，中文需注意排序规则对繁简体的影响。

LIKE 不能替代全文检索，但对简单模式匹配足够快且可控。

LIKE 的基本写法和通配符含义

LIKE 只在 WHERE 子句中起作用，必须配合字符串字段使用。它有两个核心通配符：% 匹配任意长度（含零）字符，_ 匹配单个字符。注意：% 不等价于正则中的 .*，它不支持嵌套或量词控制。

• name LIKE '张%'：匹配“张三”“张小明”“张”，但不匹配“姓张的李四”（因为开头不是“张”）
• name LIKE '%明%'：匹配中间含“明”的所有记录，但全表扫描概率高
• code LIKE 'A_2024'：匹配“A12024”“AB2024”，但不匹配“A1232024”

中文模糊搜索时的编码与排序规则陷阱

MySQL 中若字段是 VARCHAR 但用 utf8mb3 或排序规则为 utf8mb3_general_ci，可能出现“张”“張”（繁体）被当作相同字符匹配；PostgreSQL 则默认区分大小写且不自动折叠变体字。关键看字段的 COLLATION。

• 查当前字段排序规则：SHOW FULL COLUMNS FROM users LIKE 'name';
• 想让“张”“張”都命中，MySQL 可改用 utf8mb4_unicode_ci；PostgreSQL 建议用 ILIKE + unaccent() 函数预处理
• 避免在 LIKE '%关键词%' 左侧加 %——这会让索引完全失效，哪怕字段上有 B-Tree 索引

性能优化：什么时候该放弃 LIKE

当模糊条件出现在开头（如 LIKE '%abc'）或中间（'%abc%'），大多数数据库无法使用前缀索引加速。这时响应时间会随数据量线性增长，10 万行可能毫秒级，1000 万行就明显卡顿。

• 有前缀可利用索引：LIKE 'abc%' → 可走 INDEX(name)
• 无前缀但字段较短（如 6 位订单号），可建函数索引：CREATE INDEX idx_name_lower ON users ((lower(name)));，再用 LOWER(name) LIKE 'zhang%'
• 真正需要“包含任意位置关键词”的场景，应考虑 tsvector（PostgreSQL）、MATCH ... AGAINST（MySQL 全文索引）或外部方案（Elasticsearch）

别指望 LIKE 能智能分词或理解同义词；它只是字符序列比对。如果业务要求“搜‘苹果’也出‘iPhone’”，那就已经超出 LIKE 的能力边界了。