Java连接MySQL的五大高频痛点及解法：连接不通需查服务、权限、网络三关；查询变慢根因在联合索引顺序与范围字段位置；字段不同步靠DDL脚本+自动校验机制；批量操作须分片+控制事务粒度；分页崩盘应弃用limit offset，改用游标分页或延迟关联。
Java 连接和使用 MySQL 的高频痛点，不是零散的报错堆砌，而是集中在连接不通、查询变慢、字段不同步、批量卡死、分页崩盘这五个真实场景。每个问题背后都有明确的技术根因和可立即落地的解法，不需要调参玄学，也不依赖升级硬件。
连接总失败：别只填URL，先过三关
“Access denied”“Communications link failure”“Can't connect to MySQL server”看似随机，实则逃不出三个检查点：
-
MySQL服务本身是否活着：Windows 查 services.msc 中 MySQL 服务状态；Linux 执行
systemctl status mysqld，未运行就start； -
用户权限是否放行远程：默认 root@localhost 不允许外网连，必须执行
GRANT ALL ON *.* TO 'user'@'%' IDENTIFIED BY 'pwd'; FLUSH PRIVILEGES;； -
网络链路是否通透：确认
bind-address = 0.0.0.0（非 127.0.0.1），防火墙开放 3306 端口，IDEA 或 Spring Boot 中 URL 加上?serverTimezone=UTC&useSSL=false避免时区与 SSL 干扰。
查询越来越慢：先看 EXPLAIN，再动索引
慢不是因为数据多，而是索引没用对。90% 的慢查源于两个错误：
-
联合索引字段顺序反了：比如 90% 查询带
tenant_id，70% 同时带status，但索引建成了(status, tenant_id, created_at)—— 最左匹配失效，全表扫描必然发生；正确顺序应是(tenant_id, status, created_at)； -
范围条件写在了中间：例如
WHERE tenant_id = ? AND status IN (?, ?) AND created_at > ?，若索引为(tenant_id, created_at, status)，created_at是范围条件，它后面的status就无法走索引；应把范围字段（>、BETWEEN）放在联合索引最右。
Java 实体和表字段对不上：同步不能靠人盯
新增 phone 字段后 Java 报 Unknown column 'phone' in 'field list'，本质是开发流程断层。解决不靠记忆，靠机制：
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
立即学习“Java免费学习笔记（深入）”；
- 数据库变更必须走 DDL 脚本管理，且脚本需包含对应实体类更新说明；
- 用 MyBatis-Plus 的
@TableName(autoResultMap = true)+@TableField(exist = false)显式标记新增字段，避免自动映射失败； - 上线前跑一次
SELECT * FROM information_schema.COLUMNS WHERE table_name = 'xxx'对比实体字段，CI 流程中加入自动化校验脚本。
批量插入/更新卡死：别一次塞 10 万条
单条 INSERT 走事务日志+缓冲池很高效，但 10 万条拼成一大条 SQL，会撑爆内存、锁住整张表。正确做法是分片+控制事务粒度：
- MyBatis 批量用
<foreach>时，每 500～1000 条包一个INSERT INTO ... VALUES (...),(...),...； - JDBC 原生用
addBatch()+executeBatch()，配合connection.setAutoCommit(false)，每 1000 条 commit 一次； - 避免
UPDATE ... WHERE id IN (1,2,...,100000)，改用临时表 JOIN 或分批次按主键范围更新（如id BETWEEN 10000 AND 20000）。
第 1000 页查不出来：放弃 limit offset
SELECT * FROM order LIMIT 99990, 20 不是慢，是反模式。MySQL 必须扫满 100010 行才能返回结果。替代方案不是“优化”，而是“换思路”：
-
游标分页（推荐）：用上一页最后一条记录的主键值做条件，如
WHERE id > 123456 ORDER BY id LIMIT 20，无偏移、无跳扫； -
延迟关联：先查主键
SELECT id FROM order WHERE status = 1 ORDER BY id LIMIT 99990, 20，再用这些 id 回表SELECT * FROM order WHERE id IN (...)； - 业务妥协：后台系统限制最大翻页数（如只允许查前 200 页），超限提示“请用搜索或筛选缩小范围”。
