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 不定时跑，会导致优化器误判索引有效性

模糊匹配的性能陷阱不在语法多难写，而在索引能否落地、执行计划是否可控。一旦进了视图，这些控制权就容易被悄悄收走。