前缀匹配的正确写法是LIKE 'abc%'，因B-Tree索引从左到右匹配，'abc%'可定位起始位置并范围扫描，而'%abc'无确定起点需全表扫描；需注意转义、排序规则及空格处理。
LIKE语句中前缀匹配的正确写法
想查以某个字符或字符串开头的记录，必须用 LIKE 'abc%'，不能写成 LIKE '%abc' 或 LIKE 'abc'。前者是后缀匹配，后者是全等匹配，都不满足“开头”需求。
关键点在于：% 放在模式右侧才表示“后面任意内容”，左侧加 % 会拖慢查询甚至导致索引失效。
为什么 LIKE 'xxx%' 能走索引而 LIKE '%xxx' 不能
数据库（如 MySQL、PostgreSQL）对 B-Tree 索引的扫描是从左到右匹配前缀的。当模式为 'user%' 时，引擎可直接定位到 user 开头的所有索引项；但 '%user' 没有确定的起始值，只能全表扫描。
- MySQL 中，若字段有 B-Tree 索引且查询用
LIKE 'prefix%'，EXPLAIN显示type为range或ref - PostgreSQL 同样依赖
text_pattern_ops或pg_trgm扩展来优化前缀查询，但基础LIKE 'abc%'原生支持索引 - SQL Server 的
LIKE 'abc%'在有索引时也会使用Seek，而非Scan
特殊字符需要转义，否则可能误匹配
_ 和 % 是 LIKE 的通配符，如果要查真实包含下划线的前缀（比如用户名以 admin_ 开头），不转义就会出错：
SELECT * FROM users WHERE username LIKE 'admin\_%' ESCAPE '\';
常见疏漏点：
- 忘记声明
ESCAPE字符，导致语句报错或逻辑错误 - 选用了数据库不支持的转义符（如 SQLite 默认不支持
ESCAPE，需用ESCAPE ''或改用GLOB） - 字段含 Unicode 或空格时，前导空格影响匹配——建议用
TRIM()预处理，例如TRIM(username) LIKE 'john%'
区分大小写的陷阱：不同数据库默认行为不一致
MySQL 在默认 utf8mb4_general_ci 排序规则下，LIKE 'ABC%' 会匹配 abc123；而 PostgreSQL 默认区分大小写，'ABC%' 查不到 abc123。
应对方式：
- MySQL：无需额外操作，除非显式用了
_bin排序规则 - PostgreSQL：用
ILIKE替代LIKE，或写成LOWER(col) LIKE LOWER('Abc%') - SQL Server：取决于列的排序规则，可临时强制不区分大小写：
WHERE col COLLATE SQL_Latin1_General_CP1_CI_AS LIKE 'abc%'
实际写查询前，先确认目标字段的排序规则和所在数据库的默认行为，比事后调 UPPER/LOWER 更省资源。
