这事儿得从根儿上说。我刚入行那会儿，带我的老大哥扔给我一句话：“Java应用跑得慢，八成是数据库在拖后腿。”当时不服气，觉得自己写的代码逻辑挺清晰，后来线上出了几次事故，才明白这句话有多实在。你写再多花里胡哨的并发逻辑，搞再多微服务架构，数据库扛不住，一切都是白搭。说白了，Java数据库优化不是个技术问题，是个生存问题——你不想半夜被运维电话吵醒，就得从一开始把这块儿整明白。
先说索引，这玩意儿是数据库优化的第一道防线，也是最容易翻车的地方。很多新手喜欢给每个字段都建索引，觉得这样查得快，结果写操作一多，索引维护的成本直接把性能拖垮。我见过最离谱的案例，一张表建了二十多个索引，插入一条数据要等两秒。正确的做法是：只给查询频繁的字段建索引，而且得注意复合索引的顺序，把区分度高的字段放前面。比如用户表里查“状态”和“创建时间”，如果大多数查询都带时间范围，那把“创建时间”放第一个索引字段，效果会好很多。这就像你找书，先按分类找再按出版日期找，肯定比反过来快。
接着聊SQL语句本身，这是Java程序员最容易忽视的坑。很多人写代码时习惯从业务逻辑出发，觉得能跑就行，结果一条SQL拉垮整个应用。比如“select *”这种写法，看着省事，但每次查都把全表字段拉出来，网络传输和内存占用都翻倍。更糟的是，有些人在Java代码里写循环查数据库，每次循环发一次查询，这叫“N+1问题”。我接手过一个订单系统，查询列表时每条订单都要查一次用户信息，结果几十条订单的页面要等五秒才加载完。改成一次性查完所有关联数据，用JOIN或者IN子句，瞬间降到两百毫秒。写SQL的时候，脑子里得时刻绷根弦：这条语句会怎么走执行计划，有没有走索引，返回的数据量是不是最小。
执行计划这玩意儿，很多人觉得是DBA的事，但Java开发也得会看。MySQL的explain命令，Oracle的执行计划分析，这些工具能告诉你数据库是怎么执行你的SQL的。我习惯每次上线前，把核心查询的执行计划跑一遍，重点关注“type”字段是不是“ALL”（全表扫描），如果是，就得赶紧加索引或者改语句。还有“rows”字段，估算扫描的行数，如果远大于实际返回的行数，说明过滤条件没用好。有一次排查一个慢查询，发现明明有索引，但执行计划显示没走，原因是查询条件里用了函数，比如“where DATE(createtime) = ‘2024-01-01’”，这样索引就废了。改成范围查询“where createtime >= ‘2024-01-01’ and create_time < ‘2024-01-02’”，立马见效。
连接池这块儿，很多Java项目用的是默认配置，但默认不一定适合你的场景。比如HikariCP，默认连接数是10，如果你的应用并发高，10个连接可能很快就占满了，后面的请求都得排队等。反过来，连接数设太大也不行，数据库服务器撑不住，而且每个连接都占内存。我一般根据应用的平均响应时间和并发量来算，比如平均响应100毫秒，并发200，那连接数至少20到30。还有个容易忽略的点：连接泄露。有些代码里获取连接后没释放，或者释放时没放到finally块里，时间长了连接池就被耗光。用连接池监控工具定期看看，如果活跃连接数一直往上走，肯定有代码没关连接。
缓存策略是Java数据库优化的进阶玩法，但用不好反而添乱。本地缓存比如Caffeine，适合存不常变的数据，比如配置信息、字典表。分布式缓存比如Redis，适合存热点数据，比如用户会话、商品详情。但缓存有个大坑：数据一致性问题。你更新了数据库，但缓存没清掉，用户看到的是旧数据。我见过一个电商项目，价格改了之后缓存没刷新，用户下单时还是老价格，直接导致资损。解决方案也不复杂：更新数据库时，同步删除缓存，等下次查询时再重新加载。如果并发高，还得考虑缓存击穿、雪崩的问题，用互斥锁或者布隆过滤器兜底。
分库分表这事儿，很多人一上来就搞，但其实90%的场景用不上。我见过一个创业公司，用户才几万，就上了ShardingSphere，结果运维成本翻倍，查询逻辑复杂到没人敢改。分库分表是大招，不是常规手段。如果数据量到了千万级别，或者单表查询已经慢到不可接受，才考虑分。分的时候得想清楚分片键，比如按用户ID哈希分，或者按时间范围分。最怕的是分完后，查询条件里不带分片键，那就会变成全库扫描，比不分还慢。有个经验：分库分表之前，先试试读写分离、冷热数据分离，很多时候这些简单方案就能解决问题。
说个容易被忽略的点：业务逻辑层面的优化。有时候数据库慢，不是数据库的问题，是Java代码写得蠢。比如同一个事务里，先查了用户表，再查订单表，再查商品表，三个查询之间没有依赖关系，但串行执行，白白浪费了时间。改成并行查询，用CompletableFuture或者线程池，每个查询独立跑，汇总结果，能把响应时间缩短到原来的三分之一。还有种情况：批量操作时，一条一条插入，不如用批量插入，一次发几百条，减少网络往返。这些优化不需要改数据库，纯粹是代码层面的调整，但效果立竿见影。
说来说去，Java数据库优化没有银弹，也不是靠一个高深的工具就能解决。它是个系统性的活儿，从索引、SQL、连接池到缓存、分库分表、业务代码，每个环节都可能成为瓶颈。你得养成习惯：上线前压测，跑慢查询日志，看执行计划，监控连接池状态。别等到线上出问题才慌，那时候你连问题出在哪儿都找不到。数据库优化这事儿，就像修车，平时保养好了，路上才不会抛锚。
