Tomcat 只负责把请求转给后端，真正落地的数据还是要靠数据库。很多同事以为把 JDBC URL 写进 web.xml 就算完事，结果上线后报错才发现连接池根本没起作用。其实，Tomcat 自带的连接池（）配置不比手写代码差，关键在于把参数放对地方、写对格式。先把 打开，找个 节点，下面加上 ，把 name、type、driverClassName、url、username、password 这些必备信息一次性写全。别忘了给 、、、 这些性能调优的属性加上合理的数值，否则高并发时会出现连接耗尽的卡顿。
把资源声明好后，下一步是让 Web 应用能找到它。最直接的办法是在 里写个 ，把 JNDI 名称 与 里的 对齐。这样，Servlet、Spring、MyBatis 之类的框架就能通过 拿到 DataSource 实例。记得在代码里别硬写 ，否则会绕开 Tomcat 的连接池，失去统一管理的好处。很多新人在调试时会在 里直接打印 ，看到的 URL 往往是 ，这说明已经成功走通 JNDI。
如果你用的是 Spring，配置文件里只需要一行 ，然后把 加进去。Spring 会自动去 JNDI 拉取已经注册好的资源。别忘了给 设置 ，这样 Tomcat 能在空闲时检测连接是否失效，避免业务层抛出 “Communications link failure”。还有一点细节：MySQL 8 以后推荐使用 ，老的驱动类名虽然还能跑，但会触发一次不必要的警告日志。
Tomcat 的连接池还有个隐藏功能：。打开后，池子会在检测到连接泄漏时把堆栈打印出来，帮助定位是哪段代码忘记 。在本地调试时把 调低到 30 秒，能立刻看到问题。实际生产环境里一般设成 300 秒左右，防止短暂的业务高峰误判。还有 ，配合 ，让池子每半分钟检查一次空闲连接的健康状况。这样即使数据库短暂宕机，恢复后也能快速恢复连接。
别小看 与 的配合。 控制同一时间最多打开多少条物理连接，设太小会让请求排队；设太大又可能把数据库压垮。经验值是：业务高峰期每台机器的并发请求数除以 2 再乘以 1.5，得到的数值往往比默认的 100 更贴合实际。 决定请求在池子里等多久才抛异常，设成 100（10 秒）基本能让大多数短暂卡顿有机会恢复。实际调优时可以打开 Tomcat 的 日志，看每秒的 、、 指标，找到瓶颈所在。
如果你的项目里还有多个数据源，别把所有 都塞进同一个 ，会让维护变得混乱。可以在每个 Web 应用的 里单独声明，或者在 Tomcat 的 里的 里统一管理，然后在各自的 里做映射。这样做的好处是：换库、改密码时只动一处配置，部署新版本时不需要重新打包代码。实际操作中，我曾把测试库和正式库的 JNDI 名称分别设为 、，只在 里切换 ，代码不动，环境切换瞬间完成。
总体来看，Tomcat 的数据库配置并不神秘，核心在于三点：把资源写进 ，用 JNDI 在 里声明，然后在代码或框架里通过 JNDI 拿到 DataSource。细节上别忘了连接池的健康检查、泄漏日志和并发调优，这几行小配置往往决定系统在高峰期是顺畅还是卡死。把这些点都落到实处，Tomcat + 数据库的组合就能像跑步机一样，稳稳当当地跑出业务的每一次高峰。
