前缀匹配（如'abc%'）能走B-tree索引，性能好，需字段有索引、无函数包裹、%在右侧；后缀匹配（如'%xyz'）无法用常规索引，宜用倒序索引或RIGHT/SUBSTRING等函数索引替代。
用 LIKE 查询前缀匹配（如 “abc%”） LIKE 是最直接的方式，但要注意通配符位置和索引影响。前缀匹配能走索引，性能较好，前提是字段上有 B-tree 索引且没用函数包裹。
常见错误是写成 WHERE column LIKE '%abc' 却误以为这是查前缀——其实那是后缀匹配；真正前缀得把 % 放右边。
使用场景：查所有以 'user_' 开头的用户名、以 '2024-' 开头的订单号等。
-
WHERE name LIKE 'admin%'—— 匹配'admin'、'administrator' - 避免写成
WHERE UPPER(name) LIKE 'ADMIN%'，会失效索引；如需大小写不敏感，改用ILIKE（PostgreSQL）或建函数索引 - 如果前缀含下划线
_或百分号%，要用ESCAPE：例如查以'100%'开头的值，写成LIKE '100\%%' ESCAPE '\'
用 LIKE 查询后缀匹配（如 “%xyz”） 后缀匹配无法利用常规 B-tree 索引的左侧匹配特性，全表扫描风险高，尤其在大表上要警惕。
典型现象：加了 WHERE filename LIKE '%.pdf' 后查询突然变慢，EXPLAIN 显示 seq scan。
替代方案取决于数据库：
- MySQL 8.0+ 可建倒序索引：
CREATE INDEX idx_filename_rev ON files ((REVERSE(filename)))，再用WHERE REVERSE(filename) LIKE REVERSE('%.pdf') - PostgreSQL 可用
RIGHT(column, n)+ 函数索引，比如CREATE INDEX idx_ext ON files ((RIGHT(filename, 4)))，再查WHERE RIGHT(filename, 4) = '.pdf' - SQL Server 支持反向索引（
REVERSE+ 计算列索引），但需提前定义
用 SUBSTRING / RIGHT / LEFT 做精确长度截取
当后缀/前缀长度固定时，比 LIKE 更可控，也更容易命中函数索引（如果数据库支持）。
比如判断文件扩展名是否为 3 字符（'.jpg'），用 RIGHT 比 LIKE '%.jpg' 更明确，且避免 %.jpgx 被误匹配。
- PostgreSQL：
WHERE RIGHT(path, 4) = '.png' - SQL Server：
WHERE RIGHT(filename, 4) IN ('.jpg', '.png', '.gif') - MySQL：
WHERE SUBSTRING(filename, -4) = '.pdf'（注意负数表示从末尾起） - 注意 NULL 处理：若字段可能为 NULL，
RIGHT(NULL, 4)返回 NULL，不会匹配，但最好显式加AND column IS NOT NULL
正则表达式（REGEXP / ~）适合复杂模式
当需要同时匹配多个前缀、带可选字符、或中间有变化时，LIKE 力不从心，该上正则。
但代价明显：几乎所有数据库中正则都不可索引，且执行开销远高于 LIKE，只建议用于低频、小数据量或 ETL 场景。
- MySQL：
WHERE name REGEXP '^user_[0-9]{3}$' - PostgreSQL：
WHERE name ~ '^dev-.*-staging$' - SQLite（需加载扩展）：
WHERE name REGEXP '^[A-Z]{2}\d{6}$' - 别在 WHERE 中对大字段反复调用
REGEXP；如有高频需求，考虑冗余一个标记字段（如is_staging BOOLEAN）并建索引
实际选型时，先问自己：这个条件是否常用于过滤？数据量多大？前缀/后缀是否定长？——很多“必须用正则”的需求，拆成两个 LIKE 或加个计算列就更稳。
