LIKE仅做字面模式匹配，%匹配任意长度字符（含零），_匹配单个字符；需注意转义特殊字符、collation影响大小写与繁简、NULL不匹配及前导%导致索引失效。
LIKE 不是万能的模糊搜索工具，它只做字面模式匹配，不理解语义、不分词、不处理同义词。用对了快且简单，用错了查得慢还漏数据。
LIKE 的 % 和 _ 通配符怎么用才不翻车
两个核心通配符：% 匹配任意长度（含零）字符，_ 只匹配一个任意字符。它们必须出现在 LIKE 的 pattern 字符串里，不能单独用在等号或其它操作符中。
-
'Li%'→ 匹配 "Li" 开头的所有值，如 "Li Wei"、"Lily"；但不匹配 "Oli" 或 "Alice" -
'A_C'→ 要求 A 开头、C 结尾、中间**恰好一个**字符，如 "ABC"、"A2C"；不匹配 "AC"（中间缺字符）或 "ABBC"（中间多字符） -
'%数据库%'→ 中文没问题，但注意字段 collation：MySQL 用utf8mb4_general_ci时，“数据库”和“資料庫”可能不等价；PostgreSQL 默认区分繁简，需配合unaccent()或改用ILIKE - 别写
'%abc%'然后指望索引加速——B-Tree 索引对前导%完全失效，100 万行表可能秒变秒级响应
搜索内容里真有 % 或 _ 字符怎么办
比如查订单号 'PO-2024-10%' 或用户名 'a_b'，直接写 LIKE '%10%%' 会出错：第二个 % 被当成通配符，不是字面意思。
- 必须用
ESCAPE子句定义转义字符，例如：WHERE order_no LIKE '%10!%' ESCAPE '!'才能准确匹配含"10%"的字符串 - 转义符选
!、\、#都可以，但要确保它不出现在实际 pattern 里，且在数据库中未被其他语法占用 - SQL Server 还要额外处理单引号：参数值中的
'得写成''，否则语法错误 - 方括号
[]是扩展通配符（如[abc]），但它本身也是特殊字符，若要字面匹配'['，得写成'[[]'，且这个替换必须最先做
大小写和 NULL 值经常被忽略的细节
LIKE 的行为高度依赖数据库默认 collation 和字段定义，不是写完就跑通的“通用语法”。
- MySQL 默认
utf8mb4_general_ci不区分大小写，但换成utf8mb4_bin就区分；PostgreSQL 默认区分，要用ILIKE或显式LOWER(name) LIKE 'zhang%' -
name LIKE '张%'在某些 collation 下可能漏掉“張”（繁体），不是 bug，是排序规则没配对 -
NULL值永远不匹配任何LIKE表达式，哪怕写col LIKE '%'也得不到NULL行；真要包含空值，得加OR col IS NULL - 参数化查询必须保留引号：用占位符时，pattern 应传
'张%'字符串，不是张%——少引号会报错或逻辑错乱
真正卡住人的从来不是语法写不对，而是查着查着发现“明明有数据却没出来”，然后花半天才发现是 collation 区分了大小写、或是 NULL 被静默过滤、又或是 % 被当成了通配符而非字面量。这些点不提前确认，再短的 SQL 也会跑偏。
