mybatis高并发优化关键在于协同调优数据库、jvm与应用逻辑，而非修改框架本身；需合理使用一二级缓存、精准编写sql、调优连接池参数，并结合读写分离、redis缓存及分表等架构手段。
MyBatis 本身不直接处理并发，但它在高并发场景下的查询性能表现，高度依赖于底层数据库配置、SQL 编写质量、缓存策略和连接池管理。优化重点不在框架层“改 MyBatis”，而在于用好它的可扩展性，把数据库、JVM 和应用逻辑协同调优。
合理使用一级/二级缓存，但避免误用
一级缓存（SqlSession 级）默认开启，适合单次事务内重复查询，无需额外配置；但要注意它仅在同一个 SqlSession 中生效，高并发下多个请求通常走不同 Session，所以一级缓存作用有限。
二级缓存（Mapper 级）需手动开启，适用于读多写少、数据变更不频繁的场景（如商品分类、地区字典）。启用前务必确认：
- 实体类实现 Serializable 接口
- Mapper XML 中添加
或使用 @CacheNamespace 注解 - 写操作（insert/update/delete）要配置 flushCache="true"，否则可能读到脏数据
- 避免在含动态 SQL（如
嵌套过深）或关联多表的复杂查询上盲目开启，容易命中率低甚至失效
SQL 与映射层精细化控制
MyBatis 是“半自动 ORM”，优势就在于能精准干预 SQL。高并发下，慢查询往往是瓶颈根源：
- 禁用 SELECT *，只查业务真正需要的字段，减少网络传输和内存占用
- 对 WHERE 条件中高频过滤字段（如 status、create_time、user_id）建立联合索引，注意最左匹配原则
- 避免在 WHERE 中对字段做函数操作（如 DATE(create_time) = '2026-08-28'），会导致索引失效
- 分页慎用 LIMIT M,N（尤其 M 很大时），可改用游标分页（如 last_id + ORDER BY id）提升稳定性
- 用 resultMap 显式指定字段映射，避免反射开销；对简单结果可用 resultType，但注意类型安全
连接池与执行参数调优
数据库连接是关键共享资源，MyBatis 自身不管理连接池，实际由 HikariCP 或 Druid 承担：
- HikariCP 的 connection-timeout 建议设为 3000ms，避免线程长时间阻塞等待连接
- maximum-pool-size 不宜盲目调大（如设到 200），应结合数据库最大连接数（max_connections）和应用 QPS 综合评估，常见生产值为 20~50
- 开启 prepareStatement 缓存（useServerPrepStmts=true&cachePrepStmts=true），降低 SQL 解析开销
- MyBatis 配置 defaultExecutorType=REUSE 或 BATCH（批量插入/更新场景），但注意 BATCH 模式下事务不可回滚部分操作
配合数据库与架构层面协同优化
单靠 MyBatis 调优有上限，必须联动底层支撑：
- 读写分离：将报表类、列表页等只读查询路由到从库，减轻主库压力
- 引入 Redis 缓存热点查询结果（如首页推荐、热门商品），设置合理过期时间与主动刷新机制
- 对强一致性要求不高的统计类接口，可异步落库+定时聚合，避免实时 COUNT(*) 或 GROUP BY 大表
- 必要时拆分大表（按时间归档历史订单）、垂直分表（把大文本字段如 description 单独建表）
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
