上周帮一个朋友调试 Django 项目，发现他的数据库连接配置写得像天书一样，乱码、超时、连接池参数堆在一起。我问他为什么这么写，他说“网上抄的”。这让我想起刚学 Django 时，我也干过类似的事——照着文档配个 SQLite 就觉得万事大吉，直到线上环境崩了才意识到，数据库连接这件事远比想象的要复杂得多。
说实话，Django 的数据库配置在文档里写得清清楚楚，但很多新手甚至老手都容易栽在细节上。比如最常见的 SQLite，开发时用着爽，线上并发一上来就会锁表报错。我见过一个项目，用 SQLite 跑了半年，用户量从几十涨到几百，结果某天突然所有写操作都超时，查了半天发现是 SQLite 的写入锁机制导致的。所以第一个建议是：别把 SQLite 当生产环境的主力，它更适合做测试或本地开发。
生产环境里，PostgreSQL 和 MySQL 是主流。但配置时有个坑很多人踩——连接池参数。Django 默认每个请求都会新建一个数据库连接，请求结束就断开，这在低并发时没问题，但如果你的网站每秒有几百个请求，每次新建连接的开销会直接拖垮数据库。解决办法是使用持久连接，比如把 设成一个正数，如 300 秒。这样连接会被复用，但要注意，如果设得太大，连接可能闲置太久被数据库端主动断开，Django 不会自动重连，会报 “lost connection” 错误。我一般设成 60 到 300 之间，根据业务负载调节，线上跑一周观察连接池变化，再做微调。
说到连接池，还有个容易忽略的点是数据库驱动。Django 官方推荐 连接 PostgreSQL，但它本身不提供连接池，需要自行使用 或 等第三方库。MySQL 那边也有类似问题， 和 的差异会让连接池行为完全不同。我踩过最大的坑是用 连接 MySQL，结果并发一高，连接池里的连接全卡住，因为 默认是同步阻塞的，而 Django 的 ORM 在并发场景下会同时发起多个查询，导致连接池被占满。后来换回 ，问题就解决了。所以选驱动时，别只看文档说“兼容”，还要查查社区里有没有人踩过坑。
连接超时也是个老生常谈但常被忽视的问题。我见过一个电商项目，每天凌晨 3 点准时报数据库连接错误，查了半天发现是云数据库的闲置连接超时设置是 8 小时，而 Django 的 设成了 28800 秒（恰好 8 小时），正好卡在临界点。解决办法很简单：把 设得比数据库的超时时间短一点，比如设成 7200 秒（2 小时），同时加上重连机制，例如在数据库配置的 中设置 为 5 秒，这样连接断了能快速重建。还有一种做法是写一个中间件，在每次请求前检查连接是否存活，但会增加开销，我一般只在关键业务中使用。
数据库连接的读写分离，很多人觉得高大上，其实原理很简单。Django 自带的数据库路由（）就能实现，但细节里全是坑。比如你配置了主库写、从库读，但 Django 默认所有读操作都走主库，除非显式指定。我见过一个团队配了读写分离却没有做任何路由配置，结果所有查询仍打在主库上，从库完全闲置。正确的做法是写一个自定义路由类，把 、、、 分别映射到对应的数据库，同时注意事务内的读操作必须走主库，否则会出现数据不一致。还有一点：如果用了缓存（如 Redis），尽量把读操作缓存起来，减少从库压力，否则从库负载也会上去。
连接安全性这块，很多人图省事直接把数据库密码写在 里，然后上传到 GitHub。我亲眼见过一家创业公司的数据库密码在 GitHub 上挂了半年，被爬虫扫到后直接删库跑路。解决办法很简单：使用环境变量或单独的配置文件，例如在 中读取 ，并把 文件加入 。进阶做法是使用 Vault、AWS Secrets Manager 等密钥管理服务，但小项目完全可以靠环境变量。连接一定要使用 SSL/TLS 加密，尤其是跨公网访问数据库时，否则密码和查询内容都是明文传输。Django 的数据库配置里有 参数，可以指定 SSL 证书路径，千万别省这一步。
说说连接监控。很多人觉得数据库配置好了就能高枕无忧，直到线上崩了才去查日志。我习惯在项目里加一个数据库连接池的监控中间件，比如使用 或自己写的装饰器，统计每次查询的耗时、连接数、重连次数。这些数据扔进 Grafana，能直观看到连接池的使用率。有一次我发现连接池使用率在下午 3 点突然飙升到 90%，查日志发现是一个爬虫在疯狂请求，导致连接被占满。有了监控，我才能在 10 分钟内定位问题并封掉爬虫 IP，否则等用户投诉，损失就大了。
数据库连接这件事，说大不大，说小不小。它不像业务逻辑那样每天被讨论，但一旦出问题，整个系统就瘫痪。我见过太多项目，代码写得天花乱坠，却死在数据库连接上。所以别嫌麻烦，花点时间把连接池、超时、读写分离、安全、监控这些基础配置搞扎实，比写 100 个花哨功能都管用。毕竟，用户不会因为你用了 Redis 就夸你，但会因为页面打不开而骂你。
