java中mysql like查询性能优化关键在于让sql走索引：前缀匹配用like '张%'；后缀匹配建反向虚拟列索引；全模糊应改用fulltext或es；配合时间范围过滤和limit分页。
Java 中调用 MySQL 的 LIKE 查询本身不慢，慢的是没做适配的写法——比如 WHERE name LIKE '%关键词%' 在百万级数据上基本等于全表扫描。要实现高性能，关键不是“怎么写 SQL”，而是“怎么让这条 SQL 走索引 + 怎么绕过索引失效场景”。下面从 Java 应用层出发，讲真正落地有效的做法。
前缀匹配：最简单也最有效的优化
当用户搜“张”开头的名字，用 LIKE '张%' 就能直接走 B+ 树索引。Java 里只需确保参数拼接不破坏前缀结构：
- ✅ 正确写法（MyBatis 示例）：
WHERE name LIKE #{prefix} || '%'，传参"张" - ❌ 错误写法：
WHERE name LIKE CONCAT('%', #{keyword}, '%')—— 函数导致索引失效 - 字段必须有普通索引（如
INDEX idx_name (name)），且字符集建议用utf8mb4_0900_as_cs避免排序歧义
后缀匹配：用反向索引 + 虚拟列绕过限制
搜“.pdf”或“_backup”这类结尾内容时，LIKE '%.pdf' 原生不走索引。MySQL 5.7.6+ 可用虚拟列自动反转：
- 建表时加虚拟列：
ALTER TABLE files ADD COLUMN name_rev VARCHAR(255) AS (REVERSE(name)) STORED; - 为它建索引：
CREATE INDEX idx_name_rev ON files(name_rev); - Java 查询改写为：
WHERE name_rev LIKE REVERSE('%.pdf')→ 实际变成WHERE name_rev LIKE 'fdp.%'，可走索引 - 无需在 Java 层维护反转逻辑，数据库自动计算，应用无感
全模糊查询：别硬扛，换 FULLTEXT 或外部引擎
像“包含关键词但位置不定”的需求（如文章正文搜索），LIKE '%关键词%' 即使加索引也没用。这时应切换技术栈：
- 小数据量（MATCH() AGAINST()，Java 中写成
WHERE MATCH(title, content) AGAINST(#{kw} IN NATURAL LANGUAGE MODE) - 中大型数据（10 万~1000 万）：同步数据到 Elasticsearch，Java 用 RestHighLevelClient 发送 fuzzy query，响应更快、支持分词和相关性排序
- 避免在 Java 里拼接
'%' + kw + '%'然后扔给 MySQL——这是性能黑洞，不是解决方案
查询控制：从 Java 层掐住性能风险点
再好的索引也架不住乱用。Java 侧要主动拦截高危操作：
- 对用户输入做长度限制（如最多 10 个字符），防止
LIKE '%a%b%c%d%e%...'类低效模式 - 关键词含通配符（
%或_）时，强制要求开启 ESCAPE 并校验转义逻辑，避免注入或误匹配 - 结合业务加前置过滤条件，例如：
AND status = 1 AND create_time > '2025-01-01'，大幅缩小扫描范围 - 分页必加
LIMIT，禁止无限制SELECT * FROM ... LIKE '%x%'—— 即使走索引，返回 10 万行照样拖垮连接池
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
