LIKE '%abc' 拖垮视图查询性能是因为无法使用B-Tree索引，导致全表扫描；视图无数据仅封装逻辑，嵌套JOIN或聚合会进一步放大代价；EXPLAIN显示type: ALL、rows接近总行数，MySQL提示Using filesort，PostgreSQL出现Seq Scan；前缀模糊可走索引，后缀和中缀不可；函数包裹如UPPER()使索引失效；PostgreSQL可通过pg_trgm扩展+GIN索引优化'%abc%'查询。
为什么 LIKE '%abc' 会拖垮视图查询性能
因为数据库无法对这种后缀或全模糊模式使用 B-Tree 索引，哪怕字段上有索引，也会退化为全表扫描。视图本身不存数据，只是封装了查询逻辑，所以视图里用 LIKE '%abc' 或 LIKE '%abc%'，等价于在底层表上强制扫全表——尤其当视图还嵌套了 JOIN 或聚合时，代价会被放大数倍。
常见错误现象：EXPLAIN 显示 type: ALL、rows 接近表总行数、执行时间从毫秒跳到秒级；MySQL 会提示 Using where; Using filesort，PostgreSQL 则常出现 Seq Scan 即使字段有索引。
- 前缀模糊（
LIKE 'abc%'）能走索引，但后缀（LIKE '%abc'）和中缀（LIKE '%abc%'）基本不能 - 视图里如果用了
UPPER(col) LIKE UPPER('%abc%')，函数包裹会让索引彻底失效 - 某些场景下开发者误以为“加了索引就安全”，其实索引列必须以可下推的方式出现在 WHERE 条件最外层
PostgreSQL 中用 pg_trgm 加速 LIKE '%abc%'
PostgreSQL 的 pg_trgm 扩展把字符串拆成三元组（trigram），支持高效中缀匹配，并能配合 GIN 索引大幅降低扫描量。它不是“替代 LIKE”，而是让 LIKE 在原本不可索引的场景下变得可索引。
使用前提：你用的是 PostgreSQL（≥9.1），且有权限创建扩展和索引。
- 先启用扩展：
CREATE EXTENSION IF NOT EXISTS pg_trgm; - 在目标字段建 GIN 索引：
CREATE INDEX CONCURRENTLY idx_col_trgm ON my_table USING GIN (col gin_trgm_ops); - 查询保持原样：
SELECT * FROM my_view WHERE col LIKE '%abc%';—— 索引会自动生效 - 注意：
pg_trgm对短字符串（如长度 zhparser 或提前分词，否则按字节切 trigram 效果有限
MySQL 8.0+ 用全文索引 + MATCH ... AGAINST 替代 LIKE '%abc%'
MySQL 原生不支持 trigram，但 8.0+ 的倒排全文索引（InnoDB 表）能在一定约束下替代中缀模糊。关键不是“支持模糊”，而是换一种语义更明确、引擎更擅长的匹配方式。
适用场景：字段内容是自然语言文本（如商品描述、日志摘要），且你能接受“相关性排序”而非精确字符匹配。
- 建全文索引：
ALTER TABLE my_table ADD FULLTEXT(col); - 视图中改写 WHERE：
MATCH(col) AGAINST('abc' IN NATURAL LANGUAGE MODE)（不支持通配符，但能命中含 abc 的词） - 若必须支持前缀/中缀，可用布尔模式：
MATCH(col) AGAINST('abc*' IN BOOLEAN MODE)——*是通配符，但只支持末尾 - 坑点：全文索引默认忽略停用词和少于 4 字符的词（
ft_min_word_len=4），需调参；且MATCH不能和LIKE混用在同一条件中下推
视图里别写模糊逻辑，把过滤提到外部查询
最直接有效的办法，其实是让模糊匹配不出现在视图定义里。视图应专注结构抽象（JOIN、计算字段、权限裁剪），不承担低效过滤责任。
比如一个叫 v_user_with_order_count 的视图，本不该包含 WHERE name LIKE '%x%'；正确做法是视图只做关联和聚合，真正模糊查的时候再套一层：
SELECT * FROM v_user_with_order_count WHERE name LIKE '%x%';
这样至少能利用物化 CTE（PostgreSQL）、临时结果集（MySQL 8.0+）或客户端缓存减少重复计算。更重要的是，应用层或中间层可以基于实际参数决定是否走全文、是否降级为应用层过滤、是否加缓存 key。
- 视图嵌套越深，优化器越难生成好执行计划；模糊条件一旦写死在视图里，连
HINT都难干预 - 如果业务真需要“视图即接口”，建议用 SQL 函数（如 PostgreSQL 的
FUNCTION）代替视图，支持传参并内联执行计划 - 别忘了检查视图依赖表的统计信息是否过期——
ANALYZE不定时跑，会导致优化器误判索引有效性
模糊匹配的性能陷阱不在语法多难写，而在索引能否落地、执行计划是否可控。一旦进了视图，这些控制权就容易被悄悄收走。
