LIKE查不到带空格或特殊字符的字段值，因默认不忽略空格且不转义特殊符号；需用TRIM()清理空格，或ESCAPE指定转义符处理\_、%等。
LIKE 为什么查不到带空格或特殊字符的字段值
MySQL 的 LIKE 默认按字符逐位比对，不忽略首尾空格，也不自动转义特殊符号。如果字段值是 ' apple '（含前后空格），而你写 WHERE name LIKE 'apple'，结果为空——因为实际存储值和模式串长度、内容都不匹配。
- 用
TRIM()清理再匹配：WHERE TRIM(name) LIKE 'apple' - 想匹配含下划线
_或百分号%的真实字符？必须用ESCAPE指定转义符，比如查用户名为'user%2023'，得写：WHERE username LIKE 'user\%2023' ESCAPE '\' - 注意：
_匹配任意单字符，%匹配任意长度字符（包括零个）
LIKE 和 FULLTEXT 索引在性能上的关键区别
LIKE 查询只有在模式不以 % 开头时才可能走普通 B+ 树索引，例如 name LIKE 'abc%' 可用索引；但 name LIKE '%abc' 或 name LIKE '%abc%' 一定全表扫描。而 FULLTEXT 是专为文本搜索设计的倒排索引，支持自然语言模式和布尔模式，但仅适用于 MyISAM 和 InnoDB 表的 CHAR/VARCHAR/TEXT 字段，且需显式创建索引。
- 建全文索引：
ALTER TABLE articles ADD FULLTEXT(title, content);
- 查询示例：
SELECT * FROM articles WHERE MATCH(title, content) AGAINST('database' IN NATURAL LANGUAGE MODE); - 别指望
FULLTEXT支持LIKE那种通配位置灵活性，它不认%，也不支持前导通配
中文模糊匹配为什么经常失效
直接用 LIKE '%关键词%' 查中文，在多数默认配置下看似能返回结果，但实际依赖字符集排序规则（collation）。如果字段是 utf8mb4_general_ci，它对某些中文字符的比较不精确；更严重的是，LIKE 不做分词，无法识别“数据库”和“数据”之间的语义包含关系。
- 确保字段字符集统一为
utf8mb4，排序规则推荐utf8mb4_unicode_ci或utf8mb4_0900_as_cs（大小写敏感时） - 短文本可配合
CONVERT()强制编码：WHERE CONVERT(name USING utf8mb4) LIKE '%数据库%'，但治标不治本 - 真正要支持中文模糊/相似检索，得上
MeCab+NLP预处理，或换 Elasticsearch
如何安全地拼接用户输入进 LIKE 参数
把用户提交的搜索词直接拼进 SQL，比如 "%{user_input}%"，等于敞开 SQL 注入大门。即使加了 mysql_real_escape_string（PHP）或 escape（Python MySQLdb），也无法阻止 % 和 _ 被解释为通配符。
- 用参数化查询是底线：
cursor.execute("SELECT * FROM users WHERE name LIKE %s", (f"%{keyword}%",)) - 若 keyword 本身含
%或_，需先转义再拼：keyword.replace('\\', '\\\\').replace('%', '\%').replace('_', '\_')，然后在 SQL 中加ESCAPE '\' - 永远不要信任前端传来的
search=abc%—— 它可能就是一次试探性注入
LIKE 的边界很清晰：适合简单、结构化、已知前缀的模糊场景。一旦涉及多字节字符、语义扩展、高并发全文检索，就得跳出它去看更合适的工具。很多人卡在“能跑就行”，却没意识到慢查询日志里那条 LIKE '%xxx%' 正在拖垮整个实例。
