我刚接手一家公司的 Confluence 运维时，第一件事就是被他们的数据库配置整懵了。原本以为它只是个普通的文档管理工具，装上去就能跑，结果发现对数据库的要求还真不低。Confluence 本身是基于 Java 开发的，底层使用 Hibernate 做 ORM 映射，这意味着它对数据库的配置细节特别敏感。随便选个默认设置，用不了多久就会遇到各种稀奇古怪的报错，比如连接池耗尽、事务超时、索引失效。最要命的是，一旦数据库配置出问题，整个团队的工作流都会停摆——文档打不开、页面加载不出来，甚至出现数据丢失，那场面真叫一个惨。
先说数据库选型。Confluence 官方支持的主要是 MySQL、PostgreSQL 和 Oracle，但很多团队图省事直接上 MySQL。MySQL 确实上手快，但坑也不少。比如 MySQL 的默认隔离级别是 REPEATABLE READ，而 Confluence 推荐的是 READ COMMITTED，不然在高并发下会出现死锁。我见过一个团队，Confluence 跑着跑着突然卡死，日志里全是 “Deadlock found when trying to get lock; try restarting transaction” 的错误，后来才知道他们用了默认配置跑了半年。解决办法很简单：把 MySQL 的配置文件里隔离级别调成 READ COMMITTED，同时把连接超时时间设长一点，否则频繁重连也会拖垮性能。PostgreSQL 相对省心，默认配置就能跑，但要注意字符集必须是 UTF-8，不然中文内容会出现乱码。
连接池配置是另一个容易踩坑的地方。Confluence 默认使用 C3P0 连接池，但默认参数太保守。比如 maxConnections 默认只有 20，如果团队上百人同时在线，写文档、传附件、查历史版本，20 个连接根本不够，很快就会报 “Connection pool exhausted” 的错误。我建议根据团队规模动态调整：50 人以内设 50 个连接，100 人以上至少 100 个，同时把最小空闲连接数设为 10，避免频繁创建和销毁连接。还有一个关键参数是 connectionTimeout，默认是 30 秒，对 Confluence 这种需要长时间渲染页面的应用来说太短，建议调到 120 秒。另外，记得开启连接池的自动重连功能，否则数据库重启一次，Confluence 就需要手动重启才能恢复。
索引优化是数据库配置里最容易被忽略的部分。很多人装完 Confluence 就只管用，从不查看数据库索引的情况。但 Confluence 的查询逻辑特别依赖索引，尤其是 content 表、spaces 表和 attachments 表。比如 content 表的 title 字段如果没有索引，用户搜索文档标题时，数据库就得全表扫描，数据量大时响应时间直接冲到十几秒。我习惯每季度跑一次慢查询日志，把执行时间超过 1 秒的 SQL 抓出来分析，然后加合适的索引。比如经常按空间 ID 查询页面，就给 spaceid 字段加索引；经常按创建时间排序，就给 creationdate 加索引。索引不是越多越好，但关键字段缺失会直接影响用户体验——想象一下，点开文档要等十秒才加载出来，谁还有耐心继续用？
事务配置也需要特别注意。Confluence 的很多操作都是事务性的，比如保存页面、移动附件、修改权限。如果事务超时时间设得太短，大文件上传或批量操作就容易中断。我见过一个团队，上传一个 50 MB 的 PDF 附件，结果事务超时回滚，文件没传上去，还导致页面状态不一致。解决办法是把事务超时时间从默认的 30 秒改成 300 秒，同时把事务隔离级别从 SERIALIZABLE 降到 READ COMMITTED，后者在并发场景下性能更好。还有一个细节：Confluence 的数据库驱动版本要选对。比如 MySQL 的 Connector/J，5.1 版和 8.0 版在连接字符串上有差异，用错了会导致 SSL 握手失败或时区解析错误，这类问题排查起来特别费劲。
日志和监控配置也值得单独拎出来说。很多人觉得数据库配置就是改改参数，装完就完事了，但真正的问题往往隐藏在运行日志里。Confluence 的 atlassian-confluence.log 会记录所有数据库连接超时、SQL 执行错误、连接池耗尽的信息。把这些日志接入监控系统，比如 ELK 或 Grafana，实时查看数据库连接使用率、慢查询次数、事务回滚率。我习惯设一个告警规则：如果连接池使用率超过 80% 持续 5 分钟，或者慢查询数量每小时超过 100 条，就自动发邮件通知运维团队。这样能在问题爆发前介入，而不是等用户骂上门才去查数据库。
备份策略也是数据库配置的一部分，却常被忽略。Confluence 的数据库里存放所有文档内容、用户权限、评论和附件元数据，一旦出问题，恢复起来特别麻烦。我建议使用 mysqldump 或 pg_dump 做全量备份，每天一次，同时开启 binlog 做增量备份，每 15 分钟一次。备份文件要存到不同的存储节点上，防止数据库服务器挂掉时备份也一起失效。恢复时要注意数据库版本的一致性，例如 MySQL 5.7 的备份不能直接恢复到 8.0，否则字符集和排序规则可能会乱。最好在测试环境里定期演练恢复流程，别等到真出事才发现备份文件是坏的。
说说迁移和升级时数据库配置的注意事项。很多团队从旧版 Confluence 升级到新版，或从 MySQL 迁移到 PostgreSQL，结果发现页面打不开、数据查不到。根本原因是新旧版本对字符集、时区、大小写敏感度的要求不一样。比如旧版 Confluence 可能使用 latin1 字符集，升级后要求 UTF-8，数据转换过程中中文内容就会变成乱码。迁移前一定要先跑一遍官方提供的数据库一致性检查工具，把索引、外键、约束都检查一遍，有问题提前修复。升级过程中最好把数据库参数调成和旧版一致，等系统稳定运行一周后再慢慢调整。毕竟 Confluence 是团队的核心协作工具，数据库配置出问题，影响的不是一个人，而是所有人。
