mysql中using temporary和using filesort本质是sql未走索引或索引设计不当所致，优化核心在于sql写法与覆盖where、group by、select的联合索引设计，而非jvm或连接池调优。
Java 应用里 MySQL 出现 Using temporary 和 Using filesort，本质不是 Java 的问题，而是 SQL 本身没走索引、或索引设计错位导致的。优化重点在 SQL 写法和索引结构，而不是调 JVM 参数或改连接池配置。
索引必须覆盖 WHERE、GROUP BY、SELECT 三部分
MySQL 的 GROUP BY 默认要排序+归并，只有索引能“天然连续”提供分组值时才免临时表。比如：
SELECT category, COUNT(*) FROM product WHERE status = 1 GROUP BY category;- 正确索引是
INDEX(status, category)—— 等值条件放最左，分组字段紧随其后 -
INDEX(category)或INDEX(status, created_at)都无效：前者不覆盖 WHERE，后者中断最左前缀 - 如果 SELECT 还带
MAX(price)，且需要它走 Loose Index Scan，price 必须是索引第三列：(status, category, price)
别依赖 ORDER BY NULL 治标不治本
加 ORDER BY NULL 只能去掉隐式排序（避免 Using filesort），但救不了 Using temporary：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
- 适用场景：后台导出、API 返回后端自己排序、前端分页不依赖 DB 顺序
- 不适用场景：结果需按 category 升序展示，又没建
(category)或(status, category)索引 - 注意：加了
ORDER BY NULL却还查*或多个非聚合字段，临时表照样膨胀，内存不够仍会落盘
Java 层配合做的几件事
SQL 和索引定好后，Java 侧可辅助收敛风险：
- 禁用 ORM 自动生成的无意义排序，比如 MyBatis-Plus 的
orderBy或 JPA 的@OrderBy注解，若业务不需要就删掉 - 查询只取必要字段，避免
SELECT *；尤其别把 TEXT/BLOB 字段拖进 GROUP BY 查询，它们会让临时表强制落磁盘 - 用
PreparedStatement绑定参数，防止字符串拼接引发隐式类型转换（如WHERE user_id = '123'对比WHERE user_id = 123），导致索引失效 - 在测试环境开启慢日志 +
log_queries_not_using_indexes = ON，抓出 Java 调用中高频落地磁盘的 SQL，针对性优化
参数调优只是兜底，不是首选
tmp_table_size 和 max_heap_table_size 可设为相同值（如 64M），但前提是内存充足且监控显示 Created_tmp_disk_tables / Created_tmp_tables > 10%：
- 不要盲目设到 1G：每个连接独占一份，高并发下易 OOM
- sort_buffer_size 对 GROUP BY 完全无效，别动它；它只影响显式 ORDER BY 的排序阶段
- 真正该盯的是 EXPLAIN 的
Extra列：只要还有 Using temporary，调参毫无意义
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
