是，LIKE未生效常因未转义%或_：它们是通配符，需用ESCAPE指定转义符（如'\%' ESCAPE '\'）才能匹配字面值；前导通配符（'%abc'）还会导致索引失效。
WHERE子句里LIKE没生效，是不是忘了转义下划线或百分号？
直接在视图的 WHERE 子句中写 LIKE 是可行的，但常见问题不是语法错，而是通配符被当字面量用了。比如想查用户名含 _test 的记录，却写成 username LIKE '%_test%'——这里的下划线 _ 是单字符通配符，会匹配任意一个字符，不是下划线本身。
解决方法是显式指定转义字符：
- 用
ESCAPE '\'后，\_才表示字面意义的下划线，\%表示字面意义的百分号 - 写法示例：
username LIKE '%\_test%' ESCAPE '\' - 如果搜索内容来自参数（如视图封装了用户输入），必须提前对输入中的
_和%做转义处理，不能依赖前端过滤
视图定义里用LIKE会导致索引失效吗？
会，但取决于模式写法。前导通配符（如 LIKE '%abc'）基本无法走 B-Tree 索引；而 LIKE 'abc%' 在多数数据库（PostgreSQL、MySQL 8.0+、SQL Server）中仍可利用索引前缀扫描。
实际建视图时要注意：
- 避免在视图定义中固定写死
LIKE '%...%'——这会让所有基于该视图的查询都丧失索引能力 - 如果业务必须支持任意位置匹配，考虑用全文检索（如 PostgreSQL 的
to_tsvector，MySQL 的FULLTEXT）替代LIKE - 某些场景下，用生成列（generated column）+ 索引预计算模糊特征（如首字母+长度+哈希）比纯
LIKE更高效
PostgreSQL vs MySQL：LIKE的大小写敏感行为差异在哪？
根本区别在于默认排序规则（collation）。PostgreSQL 默认区分大小写，MySQL 的 utf8mb4_general_ci（旧）或 utf8mb4_0900_as_cs（新）会直接影响结果。
写跨库兼容的视图要特别注意：
- PostgreSQL 想不区分大小写：改用
ILIKE，或显式指定 collation，如username COLLATE "C" LIKE 'abc%' - MySQL 想强制区分大小写：用
BINARY修饰字段，如BINARY username LIKE 'Abc%'，或换用_bin排序规则 - 视图里混用不同 collation 可能触发隐式转换，导致索引失效或结果偏差
把用户输入拼进视图SQL里安全吗？
绝对不安全。视图是预编译对象，不能接收运行时参数。所谓“用户输入拼接”，本质是应用层动态拼 SQL 字符串再查视图——这等于把 LIKE 参数暴露给 SQL 注入风险。
正确做法只有两个：
- 用参数化查询：视图保持静态，应用传参时用占位符（如
WHERE name LIKE ?），由驱动做安全绑定 - 改用函数封装：PostgreSQL 可建
SECURITY DEFINER函数，内部校验输入并调用LIKE；MySQL 可用存储过程加ESCAPE和正则预处理 - 切记：视图定义里出现字符串拼接（如
|| '%'或CONCAT('%', input)）且输入不可控，就是高危点
LIKE 看似简单，真正麻烦的是通配符语义、索引友好性、排序规则一致性这三件事交织在一起——任何一个环节没对齐，查出来的数据就可能漏、慢、或者大小写不对。 
