Java面试里数据库那些事儿，怎么用好还得懂点优化技巧

说到Java面试里的数据库,那可真是重头戏，你不能光会说我会写个SQL查询，那太基础了，面试官想知道的，是你怎么把数据库用“好”，怎么让它和你写的Java程序高效地配合，甚至出了问题你还能知道毛病可能出在哪儿，这背后，就得懂点优化技巧了。

最最基本也最常问的,就是JDBC你怎么用，你别笑，觉得这个太简单，但很多人就栽在细节上，你知道一定要用PreparedStatement而不是Statement吗？（来源自《Java核心技术卷II》）这不仅仅是防止SQL注入攻击的安全问题，更重要的是性能，数据库会对PreparedStatement进行预编译，下次你再执行类似的SQL，哪怕参数不一样，数据库也不用再重新分析SQL语句了，直接拿来就用，快很多，还有，用完Connection、Statement、ResultSet这些资源，你得老老实实在finally块里关掉，或者直接用Java 7的try-with-resources语法，不然连接泄露了，数据库连接池一会儿就撑爆了，整个应用都可能瘫痪。

光会连接还不够,你得会管理连接，在实际项目里，我们几乎不会直接去创建数据库连接，太慢了，都是用连接池，比如HikariCP、Druid这些。（来源自网络技术社区普遍共识）连接池就像个“连接仓库”，事先创建好一批连接放着，你的Java程序要用的时候，直接从池子里借一个，用完了还回去，省去了每次建立连接、关闭连接的开销，面试官可能会问你连接池的原理，或者为什么用了连接池还会出连接不够的问题？这时候你就能谈了，可能是连接忘了归还（泄露），也可能是池子大小设置不合理，并发高的时候不够用。

说到数据库操作,百分之八十的性能问题都出在SQL本身上，索引是你必须搞明白的东西。（来源自《高性能MySQL》）你可以把索引想象成一本书的目录，没有目录，你要找某个内容，就得一页一页翻（全表扫描），慢死了，有了目录（索引），你就能快速定位到大概在哪一页，面试官最爱问：“什么情况下该建索引？”你起码得答出来：经常用来查询的字段（比如用户的手机号）、用来关联其他表的字段（外键）、还有经常用来排序分组的字段，但索引也不是越多越好，它就像书的目录，目录太详细了，书也会变厚，维护目录也要花时间，索引会占用空间，还会降低数据插入、更新、删除的速度，因为数据库不仅要改数据，还得更新索引。

光建了索引不一定有用,你得确保你的SQL语句真的用上了索引，这就涉及到SQL语句的写法了。（来源自网络技术社区常见的SQL优化经验）有些写法会让索引失效，比如在索引字段上用函数或者进行计算（where YEAR(create_time) = 2023），或者使用不等号 ，或者模糊查询时左模糊（like '%关键字'），这时候，你就得想办法改写SQL，还有，尽量避免使用 SELECT *，你需要什么字段就查什么字段，这不仅能减少网络传输的数据量，更重要的是，如果所有需要的字段都在一个索引里（这叫做覆盖索引），数据库甚至不用去查真实的数据行，直接在索引里就能把数据给你，速度飞快。

当数据量变得非常大的时候,光靠优化SQL和索引可能也不够了，就得考虑更高级的招数了，这就是常说的“分库分表”。（来源自网络技术社区对大型系统架构的讨论）简单说，就是把一个很大的数据表，按照某种规则（比如用户ID的范围、或者取模）拆分成多个小表，甚至把整个数据库都拆分成多个，这样每个小表的数据量少了，查询自然就快了，但这玩意儿是双刃剑，它会让你原本简单的联表查询变得极其复杂，事务处理也成了大难题，所以一般不是迫不得已，不会轻易上分库分表。

还有一个Java程序员容易忽略的点,就是数据库的事务。（来源自《企业应用架构模式》）事务是保证数据一致性的关键，在Java里，我们通常用Spring提供的声明式事务管理，用个 @Transactional 注解就行了，非常方便，但你得知道这个注解背后发生了什么，它的传播行为（比如一个事务方法调用另一个事务方法会怎样）和隔离级别（比如脏读、不可重复读是什么意思）是怎么回事，面试官可能会给你个场景，问你数据为什么不对了，可能就是因为事务没配置对。

Java面试中的数据库部分,绝不是背几个概念就能糊弄过去的，它要求你既有扎实的基础（JDBC、事务），又能解决实际问题（连接池、SQL优化），甚至对未来的技术挑战（分库分表）有所了解，把这些“事儿”捋清楚了，面试官会觉得你是个有实战经验的程序员，而不是只会写简单CRUD的码农。