好，我们直接聊Django的数据库连接。很多人在用Django写项目的时候，一开始根本不关心数据库怎么连的，反正配个DATABASES字典，填个地址、用户名、密码，跑起来就行。等到用户量上来了，页面卡得像幻灯片，才慌慌张张去查慢查询、加索引，甚至怀疑Django框架本身不行。其实很多时候，问题就出在最基础的连接配置上。
先说说连接池。Django默认的数据库连接机制是每次请求来的时候，新建一个连接，请求处理完就关闭。这在开发环境完全没问题，因为并发低，请求量小。但到了生产环境，尤其是用MySQL或者PostgreSQL的时候，频繁创建和销毁连接的开销非常可观。数据库服务器需要为每个新连接分配内存、做认证握手，这个成本比执行一条简单SQL语句高得多。解决办法就是用连接池，比如django-db-connection-pool或者直接让数据库驱动自带连接池功能，像psycopg2的ThreadedConnectionPool。配置好之后，连接复用率能到90%以上，响应时间直接砍半。
然后讲连接超时和健康检查。很多人配完数据库就不管了，结果半夜发警报，说数据库连不上了。一查日志，原来是连接闲置太久被数据库服务端主动断掉了，但Django这边还傻傻地拿着断开的连接去发SQL，报错“MySQL server has gone away”或者“connection already closed”。这问题怎么治？两个方向：一是设置CONNMAXAGE，让Django把连接保持一段时间再回收，一般设个300秒到600秒比较合理；二是加个自动重连机制，比如在数据库配置里加个OPTIONS，设个waittimeout或者reconnect。另外，PostgreSQL用户可以用django-dbconn-retry这个库，自动检测连接断开后重试。
接着说连接数控制。数据库服务器能同时处理的连接数是有限的，比如MySQL默认151个，PostgreSQL默认100个。如果你的Django应用开启了多进程或者多线程模式，每个进程或者线程都占一个连接，一旦并发上来，很容易把数据库的连接池撑爆。然后新请求排队等连接，用户端就感觉卡死了。合理做法是限制每个Django进程的最大连接数，比如用gunicorn跑的时候，worker数量和数据库连接数要匹配好。还有一个技巧是使用PGBouncer或者ProxySQL这样的连接代理中间件，它们能接管数据库连接，让Django应用只跟代理通信，代理再统一管理和复用真正的数据库连接，这样应用端就不需要关心连接数上限了。
说完连接，再说查询性能。连接只是第一关，真正吃性能的是SQL语句本身。很多人喜欢用Django ORM的懒加载特性，比如在一个循环里做N+1查询。举个例子，你有个Blog模型，关联了Comment模型，你遍历所有博客文章，然后访问每篇文章的comments.all()，这样每条文章都会触发一条新的SQL查询。10篇文章就变成1+10次查询，100篇就是101次。解决办法是提前用selectrelated或者prefetchrelated把关联数据一次性加载进来。selectrelated适合一对一或者外键关系，是用JOIN把数据拉回来；prefetchrelated适合多对多或者反向外键，会额外发一条查询然后把结果在Python里合并。用对了，查询次数从几十次降到两三次。
再深入一点，索引优化很多人忽视。Django ORM生成的SQL语句，如果对应的表没有合适的索引，数据库就得全表扫描。比如你用filter(namecontains='xxx')，这个like查询如果name字段没索引，数据量一大就是灾难。更隐蔽的是排序和分组操作，比如orderby('createdat')，如果createdat没索引，数据库得先读全表再排序。Django提供了dbindex=True来给字段加索引，但要注意复合索引的问题。如果你经常同时根据userid和createdat两个字段查询，最好建一个联合索引，而不是各自建单列索引。可以用Django的Meta.indexes来定义，或者直接写原生SQL来管理。
还有一个容易被忽略的点是数据库连接的安全性和SSL配置。很多小团队用Django开发的时候，数据库直接暴露在公网上，或者内网但没加密。这样不光有被攻击的风险，有些云服务商还会强制要求启用SSL连接。配置起来其实不复杂，在DATABASES的OPTIONS里加上'ssl': {'ca': '/path/to/ca-cert.pem'}就行。但要注意，启用SSL后连接建立会多一次握手，性能会有一点损耗，不过跟数据安全比起来，这点代价完全可以接受。另外，如果你用的是RDS或者Cloud SQL这类托管服务，它们通常有内置的SSL证书管理，只需要在Django配置里指对路径就行。
谈谈监控和调优的闭环。配置做完了，怎么知道有没有效果？靠感觉不行。得在Django里加数据库查询日志，django-debug-toolbar是个好工具，但只适合开发环境。生产环境用django-querycount或者集成APM工具，比如New Relic、Datadog。重点关注几个指标：每秒查询数、平均查询时间、慢查询数量、连接池使用率。如果发现某个接口的查询次数异常高，就用django-extensions的RunProfileServer来抓一下具体的SQL执行情况。然后根据结果调整连接池大小、加索引、改查询写法。记住，没有一劳永逸的配置，数据库的负载会随着业务增长变化，定期review这些指标，才能让Django应用一直跑得稳。
总结一下，Django数据库连接这件事，说简单也简单，配个连接池、设个超时、控制好连接数、优化查询加索引，基本能解决90%的问题。但真正要做好，得把连接管理、查询优化、索引策略、安全配置和持续监控串起来形成一个闭环。别指望一个配置项解决所有问题，也别因为一开始没出问题就掉以轻心。数据库是应用的命脉，Django只是工具，真正决定性能的还是你怎么用它。
