把war包部署到服务器后，数据库问题的处理核心是：先改对配置文件里的连接地址、账号密码和驱动，再确保驱动被应用加载，最后用日志定位具体报错。 这个流程适用于Tomcat、Jetty等主流Java容器，也适用于云服务器和物理机场景，下面按实际部署顺序拆解每一步。
war包部署到服务器数据库配置的核心步骤
第一步：确定war包里的配置文件位置
war包本质是zip压缩包,配置文件往往在WEB-INF/classes目录下，常见名称有application.properties、application.yml、db.properties、jdbc.properties，如果你只有war包而没有源码，可以用解压工具直接打开查看，但不建议直接改war包内的文件，因为重新打包容易损坏结构，更稳妥的办法是从源码重新构建，或者把配置外置到服务器上。
第二步：修改数据库连接参数
打开配置文件后,你需要关注四项内容：数据库地址（URL）、用户名、密码、驱动类名，在很多线上故障里，数据库地址写成localhost是头号原因，服务器上运行的数据库可能不在本机，而是独立的数据库实例或云数据库，比如MySQL常见的地址格式是：
spring.datasource.url=jdbc:mysql://内网IP:3306/数据库名?useUnicode=true&characterEncoding=utf8&serverTimezone=Asia/Shanghai spring.datasource.username=youruser spring.datasource.password=yourpass spring.datasource.driver-class-name=com.mysql.cj.jdbc.Driver
注意区分云数据库的内网地址和外网地址,如果应用和数据库在同一私有网络，用内网地址延迟更低；如果不在同一网络，才考虑公网地址，修改后务必保存，保持文件编码为UTF-8，否则中文注释或密码可能变成乱码。
第三步：把数据库驱动放到正确位置
缺少驱动是war包部署后启动报错的常见原因,日志会提示ClassNotFoundException或No suitable driver，驱动jar包有两个去处：
- 打进war包：在构建工具（Maven或Gradle）中把数据库驱动声明为编译依赖，打包后驱动会在
WEB-INF/lib目录里。 - 放到Tomcat的lib目录：如果多个应用共用数据库，可以这样做，但要注意驱动版本冲突风险。
业内专家指出,对于单个应用，把驱动打进war包更干净，避免影响同容器里的其他应用。
第四步：部署启动并观察日志
把war包放进Tomcat的webapps目录，然后启动Tomcat，日志在logs目录下，重点看catalina.out和localhost.log，出现Connection refused说明网络不通，出现Access denied说明用户名或密码错误，出现Unknown database说明库名不对，日志是解决问题的第一手信息，不要跳过这一步直接重启。
war包部署到服务器数据库连接失败怎么排查
数据库地址和端口是否可达
先检查应用服务器能否访问数据库端口,在应用服务器上执行telnet 数据库IP 3306，如果连接失败，说明网络不通，云服务器场景下，安全组和防火墙是最容易遗漏的环节，行业共识认为，云环境下的数据库连不上，多数是安全组没有放行对应端口，而不是应用代码问题，你需要同时检查云控制台的安全组规则和服务器内部的firewalld或iptables。
数据库账号是否允许远程登录
MySQL的root账号默认只允许localhost登录,如果war包部署到另一台服务器，而配置里用的是root，很可能报Access denied，解决办法是创建一个允许指定IP访问的账号，也可以给已有账号授权：
CREATE USER 'appuser'@'%' IDENTIFIED BY 'yourpass'; GRANT ALL PRIVILEGES ON yourdb. TO 'appuser'@'%'; FLUSH PRIVILEGES;
注意表示所有IP,为了安全可以换成应用服务器的内网IP。
驱动版本和数据库版本是否匹配
MySQL 8.0之后需要com.mysql.cj.jdbc.Driver，而老项目的驱动类名是com.mysql.jdbc.Driver，如果驱动jar版本太老，连接会直接失败，PostgreSQL、Oracle也有类似情况。版本不匹配的典型特征是日志提示Unable to load authentication plugin，因为新版数据库默认认证方式变了，建议使用与数据库大版本对应的驱动版本，并注意连接串中的serverTimezone参数。
配置文件是否被重新加载
修改war包内的配置文件后,如果忘了重启Tomcat，或者Tomcat缓存了旧的类，改动不会生效，更隐蔽的是，有些配置被写在了WEB-INF/classes之外的
conf目录，或者使用了JNDI数据源，你需要先确认当前应用实际读取的是哪个配置文件，而不是凭记忆猜测，可以在启动日志中搜索Loaded config file或类似信息。
war包部署后数据库乱码怎么处理
连接串明确指定字符集
乱码问题通常发生在插入或查询中文时,第一步在数据库连接URL后面加上useUnicode=true&characterEncoding=utf8，注意这里的&在配置文件中可以直接写，但在XML中需要转义为&，MySQL 8.0建议使用utf8mb4，因为它能完整支持emoji和生僻字。
数据库表结构和应用的编码保持一致
如果连接串改了还是乱码,检查数据库、表、字段的字符集，用SQL查看：
SHOW CREATE TABLE your_table;
如果看到CHARSET=latin1，那就要转换字符集，行业共识认为，应用、连接、数据库三层编码必须都统一为UTF-8或utf8mb4，单改一层解决不了问题，建议在创建表时统一指定：
CREATE TABLE your_table (...) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;
Tomcat本身也可能影响编码
如果你用的是Tomcat,修改conf/server.xml中的Connector节点，加上URIEncoding="UTF-8"，同时检查应用的过滤器或拦截器是否设置了request.setCharacterEncoding("UTF-8")，这些细节在本地开发时不容易暴露，但部署到Linux服务器后，系统默认编码往往是UTF-8，反而更容易出现不一致。
war包和jar包部署数据库配置的差异
有些项目用可执行jar包,有些用war包，两者的数据库配置方式有区别，jar包通常用外置的application.yml或启动参数指定配置，war包则依赖容器加载。jar包部署改配置只需替换外部文件，war包部署则建议把配置放到war包外部，比如Tomcat的conf目录下，或者使用Spring Boot的--spring.config.location参数，这样可以避免每次更新代码都要重新改数据库配置。
配置外置的具体做法
在tomcat的bin目录下创建setenv.sh，写入：
JAVA_OPTS="-Dspring.config.location=/opt/config/application.properties"
然后把war包里的配置文件复制到
/opt/config/下，这样升级war包时，配置不会丢失，如果你维护多个环境（开发、测试、生产），这个做法能大幅减少部署时改配置的时间。
部署前备份数据库的常用方法
无论你是升级war包还是回滚版本,数据库的安全都排第一，在修改数据库配置或执行数据迁移前，建议先做备份，MySQL常用：
mysqldump -u用户 -p 数据库名 > backup.sql
PostgreSQL用pg_dump，备份文件要存储在与数据库不同的磁盘目录，避免磁盘故障导致数据全丢，恢复时用mysql -u用户 -p 数据库名 < backup.sql，这个过程虽然不复杂，但很多线上事故就是因为没备份就改表结构或清数据。
Q&A：war部署到服务器数据库连不上怎么办
问：war包部署到服务器后，日志报“Connection refused”是什么原因？
这是应用服务器无法连接到数据库主机和端口,先确认数据库IP、端口是否拼写正确，再用telnet或nc测试网络连通，如果网络正常，检查数据库服务是否启动，以及是否绑定了0.0.1导致只接受本机连接，云服务器还要检查安全组规则是否放行了数据库端口。
问：war包部署到linux服务器数据库配置修改后，重启Tomcat还是连不上，为什么？
大概率是配置文件改错了位置,war包内的application.properties可能不是真正生效的文件，你需要检查Tomcat启动脚本是否指定了--spring.config.location，或者是否使用了环境变量覆盖配置，还有一种可能是Tomcat的work目录缓存了旧的class，执行rm -rf work/后重启再试。
问：数据库驱动已经放在Tomcat的lib目录里，但war包部署后依然报ClassNotFound，怎么办？
驱动位置没问题,问题可能出在类加载顺序，war包的WEB-INF/lib中如果有旧版本的驱动，会优先加载，导致冲突，把war包内自带的驱动移除，或者反过来把Tomcat lib下的驱动删掉，只保留一处，保持一致即可解决。
把war包部署到服务器上的数据库问题,本质上就是配置、驱动、网络三项的排列组合。任何一步出错，日志都会给出线索，关键是你愿不愿意逐行去看。 遵循从配置到日志的排查顺序，大部分问题都能在十分钟内定位。
首发原创文章，作者：王坚，如若转载，请注明出处：https://idctop.com/article/710906.html
