%匹配任意长度（含零）字符，_仅匹配单个字符；前者易致结果泛滥，后者强制长度约束，前置%使索引失效，查字面%或_须用escape转义。
% 匹配任意长度，_ 只匹配一个字符
这是最核心的区别：% 表示零个、一个或多个任意字符；_ 严格限定为恰好一个任意字符。写错会导致结果完全不对——比如想查“张三”“李四”这类两字姓名，用 LIKE '张%' 会把“张三丰”“张大锤”全捞出来；而 LIKE '张_' 才真正只命中两个字的记录。
常见错误现象：
- 用
%替代_导致结果泛滥（如查固定位数验证码却写成'%'） - 用
_替代%导致漏数据（如查“含‘数据库’的课程名”，误写成'_数据库_'，只能匹配5字且前后各1字符的极窄范围）
前导 % 会拖慢查询，_ 通常不影响索引
LIKE '%abc' 基本无法走索引，MySQL/PostgreSQL/SQL Server 都会触发全表扫描；而 LIKE 'abc_' 或 LIKE 'ab_c' 只要前缀固定（如 'ab'），仍可能利用索引快速定位。
性能影响要点：
-
LIKE 'abc%'：可走索引（前缀匹配） -
LIKE '%abc'：基本不走索引（后缀匹配） -
LIKE '_abc'：取决于字段是否建了函数索引，普通索引无效 -
LIKE 'a_c%'：前缀'a'可能部分利用索引，但中间的_和后续%会削弱效果
组合使用时要注意位置和数量对齐
% 和 _ 可以混用，但必须确保字符位数逻辑自洽。例如 LIKE 'A__C%' 表示：首字符是 A，接着两个任意字符，第4位是 C，后面任意长度——它不会匹配 'ABCD'（长度刚好4，符合），但也不会匹配 'ACD'（第4位根本不存在）。
典型误用场景：
- 查“手机号以138开头的4位后缀”，写成
LIKE '138____'是对的；写成LIKE '138%'就可能拉回11位完整号码，还得再截取 - 查“姓名第二个字是‘小’的三人名”，必须写
LIKE '_小_'；写成LIKE '%小%'会包含“王小明”“小花猫”“张小芳”等所有含“小”的记录 -
LIKE 'a_b%'匹配'axb123'，但不匹配'ab123'（因为_强制存在一个字符，不能跳过）
转义 % 和 _ 本身需要显式声明
当你要查真实含 % 或 _ 的字符串（比如价格字段存的是 '100%' 或编码含下划线 'ITEM_001'），直接写 LIKE '%100%' 会被当成通配模式，必须转义。
标准写法（以 MySQL 为例）：
- 查含字面量
%：用ESCAPE指定转义符，如LIKE '\%100\%' ESCAPE '\' - 查含字面量
_：同理，LIKE 'ITEM\_001' ESCAPE '\' - 某些数据库（如 PostgreSQL）支持用反斜杠默认转义，但 MySQL 默认不启用，必须显式加
ESCAPE - 不转义就查
'ITEM_001'，实际会匹配'ITEM001'、'ITEMA01'等任意第二位是单字符的变体
真正容易被忽略的是：不同数据库对转义的支持细节不一致——SQL Server 用 ESCAPE，Oracle 允许 ESCAPE 也支持 CHR(92)，而 SQLite 默认不支持转义，得靠 REPLACE 预处理。写跨库 SQL 时这点必须手动验证。
