我见过太多团队在数据库性能优化上栽跟头，一上来就盯着SQL语句死磕，把慢查询日志翻了个底朝天，结果收效甚微。他们忽略了一个基本事实：数据库调用的性能瓶颈，往往不在数据库本身，而在应用与数据库之间的那一段路。连接怎么建、怎么复用、数据怎么取、怎么存，这些环节的决策，对整体响应时间的影响，远超你的想象。
先说说连接池。很多人觉得连接池不就是个复用连接的容器吗，有什么好讲的。但恰恰是这个看似简单的组件，藏着最深的坑。我见过有团队把连接池最大连接数设成200，以为这样就能扛住高并发，结果数据库直接被拖垮，CPU飙到100%，应用全线超时。连接池不是越大越好，它像餐厅的座位，坐满了就得排队，但如果你把座位加到走廊上，消防通道都堵死了，反而谁都吃不上饭。合理的做法是根据数据库的QPS上限和单个连接的耗时，用利特尔法则算出一个理论值，再留30%的余量。比如你的数据库每秒最多处理1000个请求，每个请求平均耗时50毫秒，那连接池大小就是1000乘以0.05，等于50，再加点余量，设成65到70就差不多了。别拍脑袋定数字，数学不会骗人。
连接池的大小定好了，还得管好连接的“体检”。数据库连接不是永葆青春的，MySQL的waittimeout默认8小时，超过这个时间连接就被服务端掐断了，但客户端不知道，还在傻乎乎地用这个“僵尸连接”。这时候你发一个查询，直接报“Connection is not available”，或者更恶心的，报一个莫名其妙的通信异常。解决办法是定期对连接做有效性检测，比如用这种轻量查询来探活。但这里有个细节，检测的间隔不能太频繁，否则探活本身的开销就把性能优势抵消了。我见过一个团队每30秒就探一次活，结果数据库里全是的日志，那画面太美我不敢看。合理的做法是，连接空闲超过60秒才需要检测，或者干脆用连接池自带的testWhileIdle机制，设个合理的空闲检查间隔，比如5分钟。
连接池聊完，咱们说说SQL层面的优化。很多性能问题的根源，不是SQL写得烂，而是数据访问模式不合理。举个例子，N+1查询问题，这在ORM框架里特别常见。你查了100个用户，然后遍历每个用户去查他的订单，这就是100次额外的数据库调用。表面上看每次查询都很快，但加起来响应时间就爆炸了。解决思路很简单，把循环查询改成批量查询，一条搞定。但这里又有个新问题，IN子句里的参数太多，超过1000个，MySQL的优化器反而会犯迷糊，索引利用率下降。所以批量查询要分片，每500个一组，分两次查，性能反而更好。这些细节，都是在实际压测中踩坑踩出来的，光看理论书根本学不到。
接下来是缓存策略。缓存这个东西，用好了是蜜糖，用不好是砒霜。很多人一上来就搞Redis，把全表数据都塞进去，然后发现缓存和数据库的一致性维护起来痛不欲生。我见过最离谱的做法是，用户更新了一条记录，直接把整个缓存表清空，美其名曰“简单可靠”，结果缓存命中率掉到30%，数据库压力翻了三倍。正确的缓存策略，得先想清楚你的数据是什么类型。如果是字典数据，比如商品分类、地区列表，这种几乎不变的数据，缓存一天都没问题，用定时任务每天刷新一次就行。如果是用户维度的数据，比如购物车、订单列表，那得用key-value的方式，key里带上用户ID，缓存时间设短一点，比如15分钟，同时用消息队列来做失效通知，用户改了数据，发个消息把对应的key删掉。
还有一个容易被忽略的缓存层次，就是本地缓存。Redis虽然快，但网络IO还是有开销的，一次GET大概0.5到1毫秒。如果你的服务是高频调用，比如每秒几千次，这毫秒级的延迟也会累积起来。这时候可以在应用内存里再加一层缓存，用Caffeine或者Guava，把最热的数据放本地，访问延迟直接降到微秒级。但这层缓存的坑在于数据一致性，多实例部署的时候，一个实例更新了数据，其他实例的本地缓存还是旧的。解决办法是每个实例的本地缓存设个很短的过期时间，比如30秒，或者用Redis的Pub/Sub广播失效消息。记住一个原则：本地缓存只放那些容忍短暂不一致的数据，如果数据变了必须秒级生效，那就老老实实走Redis。
再往深了说，缓存穿透和缓存击穿这两个问题，几乎是每个高并发系统的噩梦。缓存穿透是指查询一个根本不存在的数据，缓存里没有，数据库里也没有，每次请求都打到数据库上。攻击者可以利用这点，构造一堆不存在的ID，把你数据库打爆。解决办法有两个，一是用布隆过滤器，把所有存在的ID先过滤一遍，不存在的直接返回空，压根不去查数据库；二是缓存空值，把不存在的key也缓存起来，设置个短过期时间，比如2分钟，这样同样的请求就不会打到数据库了。缓存击穿是指某个热点key在过期的瞬间，大量请求同时涌进来，发现缓存没有，一起冲到数据库。解决办法是加互斥锁，只有一个线程能去数据库加载数据，其他线程等待锁释放后直接读缓存。用Redisson的分布式锁就能实现，但要注意锁的粒度，别把整个key空间都锁住了。
说说监控和调优的闭环。性能优化不是一次性的工作，你不可能一劳永逸。我强烈建议每个团队都做两件事：第一，全链路追踪，用SkyWalking或者Zipkin，把从HTTP入口到数据库调用的每一步耗时都记录下来，这样你才能知道瓶颈到底在哪一层。第二，定期做压测，用JMeter或者Gatling，模拟线上流量，观察连接池的大小、缓存的命中率、SQL的响应时间，看看有没有异常波动。我见过一个团队，上线前做了压测没问题，但上线后两周就出问题了，查了半天才发现是数据量增长导致索引失效。这种问题，只有通过持续的监控和复盘才能提前发现。
回到标题，数据库调用性能优化，从连接池到缓存策略，其实是一条完整的链路。连接池管的是“连接”这个资源，缓存管的是“数据”这个资源，两者配合好了，你的数据库才能吃得少、跑得快。但别忘了，这一切的前提，是你对业务数据访问模式有深刻的理解。别迷信任何最佳实践，每个系统的数据特征不一样，适合别人的方案未必适合你。最靠谱的方法，还是扎到自己的系统里，用数据说话，压测、监控、调整，循环往复。性能优化这条路没有终点，但只要你方向对了，每一步都不会白走。
