LIKE通配符正确写法：%匹配任意长度字符，_匹配单个字符；前缀匹配（如'abc%'）可走索引，后缀（'%abc'）和全模糊（'%abc%'）通常不走索引；需注意大小写敏感性、NULL值不匹配、转义特殊字符及collation影响。
LIKE 通配符怎么写才不会查不到数据
LIKE 的核心是两个通配符：% 匹配任意长度（含零）字符，_ 匹配单个字符。写错位置或忽略大小写规则，就查不到结果。
-
%放开头（如'%abc'）表示后缀匹配，放结尾（如'abc%'）表示前缀匹配，两边都放（如'%abc%'）才是真正的“包含” - MySQL 默认不区分大小写，但 PostgreSQL 和 SQL Server 默认区分——如果查
'John'却写了LIKE 'john%'，在 PostgreSQL 里会返回空 - 想匹配字面意义的
%或_？得用ESCAPE：例如WHERE name LIKE '%100\%%' ESCAPE '\'才能查出 “折扣：100%” 这样的字符串
中文字段用 LIKE 为什么经常慢
LIKE 查询是否走索引，取决于通配符位置和字段类型。前导通配符（'%张'）基本无法利用 B-tree 索引，全表扫描就来了。
- 只有
LIKE '张%'这种前缀模式才可能走索引；LIKE '%张%'在大多数数据库里都不走索引 - UTF8MB4 字符集下，中文占 3–4 字节，但索引键长度限制（如 MySQL InnoDB 默认 767 字节）可能导致前缀索引截断，
name VARCHAR(255)实际只索引前 191 个字符——查长文本末尾内容依然慢 - 替代方案：对高频模糊查询字段加
FULLTEXT索引（MySQL）或使用pg_trgm扩展（PostgreSQL），比裸 LIKE 快得多
不同数据库对 LIKE 的行为差异
同一个 LIKE 表达式，在不同数据库里结果可能不同，尤其涉及空值、空白符和转义。
- SQL 标准规定：任何值与
NULL做LIKE比较，结果都是UNKNOWN，即该行不被返回——别忘了加OR column IS NULL如果业务需要包含空值 - SQL Server 默认把尾部空格忽略（
'abc 'LIKE'abc'返回 true），而 PostgreSQL 和 MySQL 严格按字节比较，'abc '不匹配'abc' - SQLite 不支持
ESCAPE子句，要用instr()或正则函数（需启用扩展）替代复杂模式
用参数化查询防注入时 LIKE 怎么拼接
直接拼字符串（如 "%"+userInput+"%"）等于把 SQL 注入大门敞开。参数化不是把整个 LIKE 表达式当参数，而是把通配符加到绑定值里。
- ✅ 正确做法：预编译语句中写
WHERE title LIKE ?，然后传入'%'+input+'%'作为参数值（Python/Java/Node.js 都适用） - ❌ 错误做法：写成
WHERE title LIKE '%?%'—— 大部分驱动会把?当普通字符处理，查不出东西 - ORM 如 SQLAlchemy 或 Django ORM 通常自动处理，但要注意其
ilike（PostgreSQL 不区分大小写）或contains方法底层是否真用了参数化，有些旧版本会拼接字符串
utf8mb4_0900_as_cs 和 utf8mb4_unicode_ci 对中文拼音、重音符号的处理完全不同，查“café”可能命中也可能不命中，得看字段定义里的 collation。 
