LIKE前缀匹配（如'abc%'）能走索引，%开头（如'%abc'）必全表扫描；中文需utf8mb4字符集；特殊字符须ESCAPE转义；参数化是底线；大数据量应改用全文检索或外部搜索引擎。
能用 LIKE 就别硬上正则或函数，但必须清楚它什么时候快、什么时候慢、为什么慢。
LIKE 前缀匹配（如 'abc%'）能走索引，% 开头（如 '%abc'）一定全表扫
MySQL 的 B+ 树索引只支持最左前缀匹配。当模式是 '张%' 时，只要 name 字段有普通索引，就能定位到“张”开头的索引页；但 '%张' 或 '%张%' 没法从索引树根往下跳，只能逐行读数据。
- 建索引要明确：
ALTER TABLE users ADD INDEX idx_name (name); - 字段太长（比如
TEXT）可建前缀索引：ADD INDEX idx_title_prefix (title(64)); - 不要在
LIKE左边套函数，比如LOWER(name) LIKE 'abc%'—— 索引直接失效 - 中文没问题，但确认字符集是
utf8mb4，排序规则推荐utf8mb4_unicode_ci（不区分大小写）
查含特殊字符（% 或 _）时必须 ESCAPE 转义
用户昵称存了 '100%'，你写 WHERE name LIKE '%100%%' 会匹配所有带 100 的记录，根本不是想找那个带百分号的昵称。
- 正确写法：
WHERE name LIKE '%100\%%' ESCAPE '\' - 转义符可以任意选，但前后要一致，比如用
@：LIKE '%100@%%' ESCAPE '@' - 如果输入来自前端，预处理时就得把用户输的
%和_替换成\%、\_，再拼进 SQL
参数化是底线，拼接字符串=给 SQL 注入留门
哪怕只是测试环境，也别写 "... WHERE name LIKE '%" + keyword + "%'" —— 一个单引号就能让整条 SQL 崩掉。
- PHP PDO 示例：
$stmt = $pdo->prepare("SELECT * FROM users WHERE name LIKE CONCAT('%', ?, '%')"); $stmt->execute([$keyword]); - Java JDBC 示例：
ps.setString(1, "%" + keyword.trim() + "%");（注意trim()防空格导致%%全表扫） - 前端传参前建议过滤空值、去首尾空格，后端再校验长度（比如限制 ≤ 20 字），避免恶意长关键词拖垮数据库
大数据量时，LIKE 不是搜索方案，只是临时补丁
几百万行以上，LIKE '%关键词%' 查一次可能秒级响应，但并发一上来就卡死。这不是调优能解决的。
- 全文检索优先用
FULLTEXT：建索引ADD FULLTEXT(title, content)，查MATCH(...) AGAINST('关键词') -
FULLTEXT对中文支持有限（依赖内置分词器），生产环境建议搭配 Meilisearch 或 Elasticsearch -
REGEXP更灵活但更慢，且无法走任何索引，只适合低频、小数据量校验场景 - 倒排思路可行但成本高：比如对
name同时存正序和倒序字段，查后缀时用REVERSE(name) LIKE 'cba%'走索引 —— 仅适用于固定后缀模式
真正容易被忽略的点是：模糊查询的语义边界。LIKE 只认字面匹配，不理解“手机”和“移动电话”是同义词，也不懂“iPhone15”和“苹果15”有关联。一旦业务需要相关性排序、同义扩展、拼音容错，就必须跳出 MySQL 自身能力范围。
