视图中使用LIKE与普通表无本质区别，因为视图是虚拟表，其WHERE条件会下推至基表执行；性能、大小写敏感性、NULL处理等均由底层表的数据、索引、字符集和通配符写法决定。
LIKE 在视图中和在普通表中用法完全一致，视图本身不改变 LIKE 的行为，它只是封装了查询逻辑。真正影响模糊查询效果的，是底层表的数据、索引、字符集和通配符写法。
视图里写 LIKE 和普通表有区别吗？
没有本质区别。视图是虚拟表，执行时会把你的 WHERE 条件“下推”到基表查询中。比如你创建了一个视图：
CREATE VIEW active_users AS SELECT id, name, email FROM users WHERE status = 'active';
然后对它做模糊查询：
SELECT * FROM active_users WHERE name LIKE 'Li%';
数据库实际执行的是：
SELECT id, name, email FROM users WHERE status = 'active' AND name LIKE 'Li%';
所以性能、大小写敏感性、NULL 处理等，全由底层 users 表决定，跟视图无关。
LIKE 通配符放在开头（如 '%abc'）为什么慢？
因为无法利用 B-Tree 索引的有序结构。索引按值排序存储，而 % 在前意味着要扫描所有索引项甚至回表全扫。
-
name LIKE 'abc%'：可走name字段的前缀索引（如果存在） -
name LIKE '%abc'：基本等于全表扫描，尤其在大表中明显卡顿 -
name LIKE '%abc%'：同样无法用标准索引，除非用全文索引或CONTAINS（SQL Server）/TO_TSVECTOR（PostgreSQL）
MySQL 8.0+ 支持函数索引，可建 INDEX ON (LOWER(name)) 配合 LOWER(name) LIKE 'li%' 提升大小写不敏感场景性能。
视图中搜索含 % 或 _ 的字面量怎么办？
直接写 LIKE '%50%' 是错的——它会匹配任意含 “50” 的字符串，不是想查字面量 “%50”。必须转义。
- 用
ESCAPE显式声明转义字符：WHERE code LIKE '\%50' ESCAPE '\' - 不同数据库默认转义符可能不同：MySQL 默认无，PostgreSQL 同样需显式指定；SQL Server 可用
ESCAPE或方括号[%]50 - 注意：视图定义里如果硬编码了带转义的
LIKE，后续调用时不能动态改转义符，得靠参数化或应用层拼接
更安全的做法是避免在视图里固化模糊模式，把 LIKE 条件留给查询时传入。
大小写和 NULL 值在视图模糊查询中容易被忽略
视图不会自动处理这些细节，它们继承基表行为：
- MySQL 默认不区分大小写（取决于列的 collation），但
utf8mb4_0900_as_cs就区分；写视图前先SHOW CREATE TABLE users;看清楚 -
name LIKE 'john%'在大小写敏感库中查不到John，得用LOWER(name) LIKE 'john%'或加BINARY -
NULL值永远不匹配任何LIKE表达式，包括LIKE '%'—— 所以视图结果里若缺数据，先检查字段是否为NULL
最常出问题的是：开发在测试库用小写数据验证通过，上线后因生产库 collation 不同或数据含 NULL，查询突然返回空。
