正确写法是使用预处理语句+占位符，将通配符%拼接到绑定值中，而非SQL模板内；需确保字段字符集为utf8mb4、排序规则支持中文；仅LIKE 'abc%'能走索引，全模糊应改用FULLTEXT或ES。
PHP中用PDO或MySQLi执行LIKE模糊查询的正确写法
直接拼接用户输入到SQL里的LIKE语句，99%会触发SQL注入。必须用预处理+占位符，不能用字符串拼接。
常见错误写法：$sql = "SELECT * FROM user WHERE name LIKE '%{$_GET['q']}%'"; —— 这等于把数据库大门钥匙塞给任何人。
- 正确做法：用
?或命名参数，把通配符%加在绑定值里，而不是SQL模板中 - PDO示例：
$stmt = $pdo->prepare("SELECT * FROM user WHERE name LIKE ?"); $stmt->execute(['%' . $_GET['q'] . '%']); - MySQLi示例：
$stmt = $mysqli->prepare("SELECT * FROM user WHERE name LIKE ?"); $search = '%' . $_GET['q'] . '%'; $stmt->bind_param("s", $search); $stmt->execute(); - 若需左匹配（以某字符串开头），只加右通配符：
'abc%'；右匹配则用'%abc'；全模糊才是'%abc%'
中文模糊查询时LIKE不生效？注意字符集和排序规则
明明数据里有“张三”，WHERE name LIKE '%张%'却查不到，大概率是表字段用了utf8而非utf8mb4，或排序规则不支持中文索引。
- 检查字段字符集：
SHOW CREATE TABLE user;确认name列是utf8mb4+utf8mb4_unicode_ci（推荐）或utf8mb4_general_ci -
utf8在MySQL中实际是utf8mb3，不支持4字节Unicode字符（如部分emoji、生僻汉字），会导致匹配失败 - 建表时显式指定：
name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci - 已有表可修改：
ALTER TABLE user MODIFY name VARCHAR(50) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;
LIKE查询慢？这些情况会让索引失效
LIKE '%abc'或LIKE '%abc%'基本无法走B-Tree索引，尤其是数据量大时延迟明显。不是代码问题，是MySQL的索引机制限制。
立即学习“PHP免费学习笔记（深入）”；
- 只有
LIKE 'abc%'这种前缀匹配才能有效利用索引 - 如果必须做全模糊搜索，考虑用
FULLTEXT全文索引（仅MyISAM/InnoDB支持）：ALTER TABLE user ADD FULLTEXT(name);，再用MATCH(name) AGAINST('张三' IN NATURAL LANGUAGE MODE) - 更重的场景建议接入Elasticsearch或Sphinx，PHP侧只负责调用API
- 临时缓解：加
LIMIT控制返回条数，避免全表扫描拖垮连接池
用htmlspecialchars()或addslashes()防XSS/注入？别搞混了
这两个函数对防止LIKE注入完全无效。addslashes()早被绕过多年，htmlspecialchars()只转义HTML标签，不影响SQL执行。
- 唯一可靠方案：**预处理语句（Prepared Statements）**，这是PHP官方文档明确推荐的防御方式
- 不要试图自己“过滤关键词”（比如删掉
OR 1=1），规则永远追不上攻击变种 - 如果框架封装了查询方法（如Laravel的
where('name', 'like', "%{$q}%")），确认它底层是否真正用了预处理——有些老旧扩展只是字符串替换
实际项目里最容易被忽略的是字符集配置和索引有效性。写完LIKE语句跑通结果，不代表它在线上扛得住并发或大数据量。
