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%'正在拖垮整个实例。
