LIKE在JOIN中拖垮性能是因为前导通配符（如'%xxx'）使B-Tree索引失效，导致嵌套循环全表扫描；可用FULLTEXT索引、生成列+索引或pg_trgm等方案优化。
为什么LIKE在JOIN中会拖垮性能
因为数据库无法对 LIKE '%xxx' 这类前导通配符表达式使用索引（B-Tree索引只支持最左前缀匹配），JOIN时若一方字段用 LIKE 做关联条件，优化器大概率退化为嵌套循环全表扫描——哪怕两张表各只有1万行，也可能触发上亿次字符串比对。
用FULLTEXT索引替代LIKE实现左匹配
MySQL 5.6+ 支持在 CHAR/VARCHAR 字段上建 FULLTEXT 索引，配合 MATCH ... AGAINST 实现高效前缀/包含匹配，且能用于JOIN。但注意：它不等价于 LIKE，需调整写法。
- 把
ON t1.name LIKE CONCAT('%', t2.pattern)改成ON MATCH(t1.name) AGAINST(t2.pattern IN NATURAL LANGUAGE MODE) -
t2.pattern必须是单个词或空格分隔的词组，不能含通配符；若需模糊控制，改用布尔模式：AGAINST('+abc*' IN BOOLEAN MODE) -
FULLTEXT索引要求表引擎为InnoDB或MyISAM，且字段长度不能超3072字节（InnoDB）
用生成列+索引加速右匹配（如LIKE 'xxx%'）
当模糊条件固定为右截断（LIKE 'prefix%'），可直接走B-Tree索引。但若pattern来自另一张表，需把动态右匹配转为静态索引查找：
- 在主表添加存储生成列：
ALTER TABLE users ADD COLUMN name_prefix VARCHAR(32) STORED AS (SUBSTRING(name, 1, 32)) - 在该列建索引：
CREATE INDEX idx_name_prefix ON users(name_prefix) - JOIN时改写为：
ON u.name_prefix = LEFT(p.pattern, 32)（前提是pattern长度≤32且语义等价） - 若pattern长度不固定，可用更长的截取（如64），但索引体积和内存占用会上升
用PGroonga或pg_trgm在PostgreSQL中加速任意LIKE
PostgreSQL原生不支持前导通配符索引，但扩展可解决：pg_trgm 对 LIKE '%xxx%' 有效，PGroonga 支持全文+前缀+正则混合查询。关键点在于选择与实际查询模式匹配的扩展。
- 启用
pg_trgm：CREATE EXTENSION pg_trgm，然后建GIN索引：CREATE INDEX idx_name_gin ON products USING GIN (name gin_trgm_ops) - JOIN中保持原
LIKE写法，优化器会自动命中索引——但仅对%xxx%和xxx%有效，%xxx（后缀匹配）仍慢 - 若必须支持后缀匹配（
LIKE '%suffix'），得反转字符串建索引：CREATE INDEX idx_name_rev ON products USING BTREE (reverse(name))，查询时写reverse(product.name) LIKE reverse('%suffix')
真正卡住性能的往往不是语法本身，而是没意识到 LIKE 在JOIN里根本不是“条件”，而是“驱动方式”——它强迫数据库放弃所有统计信息，回到暴力匹配。先确认你是否真的需要JOIN时模糊匹配，还是能把过滤下推到子查询或应用层预处理。
