php查询数据怎么模糊查_like通配符匹配使用场景【方法】

PHP中LIKE模糊查询必须用参数绑定防SQL注入，通配符由PHP拼接后传入预处理语句，严禁字符串拼接；需注意排序规则、索引优化、转义特殊字符及大数据量性能问题。

PHP 中 LIKE 模糊查询必须用参数绑定防 SQL 注入

直接拼接用户输入到 LIKE 语句里，哪怕加了 % 也极大概率被注入。比如：$keyword = $_GET['q']; $sql = "SELECT * FROM users WHERE name LIKE '%$keyword%'"; —— 这种写法在遇到 ' OR '1'='1 时会全表泄露。

正确做法是统一走预处理 + 占位符，通配符由 PHP 拼接后传入参数：

$keyword = $_GET['q'] ?? '';
$keyword = trim($keyword);
$stmt = $pdo->prepare("SELECT * FROM users WHERE name LIKE ?");
$stmt->execute(['%' . $keyword . '%']);

• 不要在 SQL 字符串里写 %?%，PDO 不支持这种写法，会报错 SQLSTATE[HY093]: Invalid parameter number
• 如果用 MySQLi，也得用 bind_param，不能 "%{$keyword}%" 直接塞进 query
• 前端传空字符串或只含空格时，trim() 后建议跳过查询，避免查出全部数据

LIKE 匹配中文、大小写、前导空格的实际表现

MySQL 默认的 utf8mb4_general_ci 或 utf8mb4_0900_as_cs 排序规则，直接影响模糊匹配结果：

• 带 _ci（case-insensitive）后缀的规则：自动忽略大小写，LIKE 'a%' 能命中 Apple
• 带 _as_cs（accent-sensitive & case-sensitive）则严格区分大小写和重音，'É' 和 'E' 不等价
• 中文基本无大小写问题，但需确认字段是 utf8mb4 编码，否则可能匹配失败或乱码
• LIKE ' %'（前导空格）能匹配字段开头有空格的记录；但多数业务字段用了 TRIM 入库，实际查不到

替代 LIKE '%xxx%' 的更高效方案

全模糊（前后都带 %）无法走 B+ 树索引，数据量一过万行，响应就明显变慢。真要高频搜索，别硬扛 LIKE：

• 字段加前缀索引：如 ALTER TABLE users ADD INDEX idx_name_prefix (name(10));，仅对 LIKE 'xxx%' 有效
• 用 MySQL 5.7+ 的全文索引（FULLTEXT）配合 MATCH ... AGAINST，支持自然语言模式和布尔模式
• 更重的场景上 Elasticsearch 或 Meilisearch，尤其要支持拼音、分词、同义词时
• 简单场景可预生成关键词列（如 name_pinyin），再对它做前缀匹配

LIKE 中的下划线 _ 和百分号 % 怎么转义

_ 匹配任意单字符，% 匹配任意多字符 —— 如果你要查真实含这两个字符的文本（比如查用户名 admin_2025），必须转义：

$keyword = str_replace(['_', '%'], ['\_', '\%'], $_GET['q']);
$stmt = $pdo->prepare("SELECT * FROM users WHERE name LIKE ? ESCAPE '\\'");
$stmt->execute(['%' . $keyword . '%']);

• ESCAPE '\\' 声明反斜杠为转义符，之后的 \_ 和 \% 就按字面意思匹配
• 别漏掉 ESCAPE 子句，否则 \_ 还是会被当通配符处理
• 如果用户输入本身就含反斜杠（如 C:\path），得再额外转义一次：变成 C:\\path

真正卡住人的往往不是语法，而是没意识到 LIKE 在大数据量下有多慢，或者忘了转义导致查不到数据。上线前一定用真实数据测下响应时间和执行计划。