sql中like '%.pdf'查不到记录主因是数据含路径、空格或不可见字符，以及大小写敏感性；postgresql等区分大小写时需用'.pdf'匹配，而mysql默认不区分；更健壮方式是用substring_index或正则提取扩展名再比对，并为扩展名列建索引提升性能。
SQL中用LIKE匹配文件后缀的正确写法
直接用 LIKE '%.pdf' 是最常用也最可靠的方式，但必须注意字段值是否含路径、大小写敏感性、以及数据库对通配符的处理差异。
为什么LIKE '%.pdf'有时查不到记录
常见原因不是语法错，而是数据本身干扰了模式匹配：
- 文件名存的是完整路径（如
/home/user/report.pdf），此时LIKE '%.pdf'仍能匹配——因为%可跨层级匹配任意字符 - 但若字段里混有空格或不可见字符（比如末尾有
\r或空格），'.pdf '就不等于'.pdf'，导致匹配失败 - PostgreSQL 默认区分大小写，
'%.PDF'不会匹配report.PDF；MySQL 在多数排序规则下不区分，但显式用COLLATE utf8mb4_0900_as_cs就会区分 - SQLite 的
LIKE默认不支持 Unicode 大小写折叠，'%.Pdf'可能漏掉首字母大写的后缀
更健壮的后缀提取与匹配方式
当业务要求严格按“扩展名”逻辑（即点号后纯字母数字）判断时，仅靠 LIKE 不够。可结合字符串函数增强鲁棒性：
MySQL 示例（取最后一个点后的部分再比对）：
SELECT * FROM files
WHERE SUBSTRING_INDEX(filename, '.', -1) IN ('pdf', 'docx', 'xlsx');
PostgreSQL 示例（用正则提取扩展名）：
SELECT * FROM files
WHERE filename ~ '\.[a-zA-Z0-9]{2,4}$';
注意：SUBSTRING_INDEX 在 MySQL 中安全，但在其他数据库不可用；PostgreSQL 的 ~ 运算符需确保字段无 NULL，否则整行被过滤掉。
性能和索引注意事项
LIKE 以 % 开头（如 '%.pdf'）无法使用 B-tree 索引的前缀加速，全表扫描不可避免。如果查询频繁且数据量大：
- 考虑增加计算列（如 MySQL 5.7+ 的
GENERATED COLUMN）存储扩展名，并在该列建索引 - 避免在
WHERE中对字段做函数运算（如RIGHT(filename, 4) = '.pdf'），这同样使索引失效 - SQLite 中可建
COLLATE NOCASE索引缓解大小写问题，但无法优化%开头的模糊查询
真正难处理的其实是那些看似简单、实则被路径分隔符、编码异常或隐式类型转换悄悄破坏的匹配场景。
