直接查看慢查询日志是定位java应用中mysql性能隐患最有效、最落地的第一步，无需代码改动或服务重启，能真实反映线上sql执行情况；需先检查并开启慢查询日志，再通过日志分析query_time、rows_examined、索引使用情况，结合explain和java应用上下文（如mybatis sql写法、分页逻辑、参数类型）综合优化。
直接看慢查询日志，是定位Java应用里MySQL性能隐患最有效、最落地的第一步。它不依赖代码改动，也不需要重启服务（临时开启即可），能真实反映线上SQL的实际执行表现。
确认并开启慢查询日志
先检查当前状态，再决定是临时启用还是永久配置：
- 登录MySQL执行：SHOW VARIABLES LIKE 'slow_query_log'; —— 若返回 OFF，说明未开启
- 临时开启（立即生效，重启失效）：SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 2;
- 永久开启更推荐：编辑my.cnf的[mysqld]段，加入以下几行（路径需确保MySQL有写权限）：
slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 2
log_queries_not_using_indexes = 1
min_examined_row_limit = 1000
保存后重启MySQL服务
快速定位问题SQL
日志文件是纯文本，每条记录包含执行时间、扫描行数、锁等待、用户和完整SQL。重点关注三类信号：
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
- Query_time 超阈值：比如Query_time: 8.423156，明显高于设定的2秒
- Rows_examined 远大于 Rows_sent：如扫描了50万行只返回20条，大概率存在全表扫描或索引失效
- 没走索引的提示：日志里出现"No index used"或"Not using index"字样，即使执行快也该优化
用 EXPLAIN 深挖执行计划
把慢日志里的SQL复制出来，前面加EXPLAIN再执行，重点盯这几个字段：
- type：优先看到const、ref；如果出现ALL，就是全表扫描
- key：显示实际使用的索引名；若为NULL，说明没走索引
- Extra：警惕Using filesort（排序未走索引）、Using temporary（临时表）、Using where; Using index是理想状态
结合Java应用上下文验证
光看数据库不够，要回溯到Java层确认调用场景：
- 查MyBatis Mapper XML或注解SQL，确认是否写了SELECT *、LIKE '%xxx'、函数包裹字段（如DATE(create_time)）等典型陷阱
- 检查分页逻辑：是否用了LIMIT 10000,20这类深分页，导致MySQL跳过大量数据
- 核对参数传入：比如Java传入的是String类型ID，而数据库字段是BIGINT，隐式转换会让索引失效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
