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：
论文常用的tex格式转换为word格式，核心是能转换数学公式（非图片），表格，图表等等
下载
将 LaTeX（.tex）学术论文转换为 Word（.docx），支持可编辑的 OMML 公式、原生 Word 表格、嵌入图形、IEEE 双栏排版及参考文献
立即学习“PHP免费学习笔记（深入）”；
- 字段加前缀索引：如
ALTER TABLE users ADD INDEX idx_name_prefix (name(10));，仅对LIKE 'xxx%'有效 - 用 MySQL 5.7+ 的全文索引（
FULLTEXT）配合MATCH ... AGAINST，支持自然语言模式和布尔模式 - 更重的场景上 Elasticsearch 或 Meilisearch，尤其要支持拼音、分词、同义词时
- 简单场景可预生成关键词列（如
name_pinyin），再对它做前缀匹配
LIKE 中的下划线 _ 和百分号 % 怎么转义
_ 匹配任意单字符，% 匹配任意多字符 —— 如果你要查真实含这两个字符的文本（比如查用户名 admin_2024），必须转义：
$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 在大数据量下有多慢，或者忘了转义导致查不到数据。上线前一定用真实数据测下响应时间和执行计划。
