直接查看慢查询日志是定位java应用中mysql性能隐患最有效、最落地的第一步，无需代码改动或重启服务，能真实反映线上sql执行表现，并通过explain分析、java上下文回溯精准优化。
直接看慢查询日志，是定位 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。重点关注三类信号：
- 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)）等典型陷阱
- 检查分页逻辑：是否用了深分页，导致 MySQL 跳过大量数据
- 核对参数传入：比如 Java 传入的是 String 类型 ID，而数据库字段是 BIGINT，隐式转换会让索引失效
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
