Nginx 不能代理数据库，因其不支持 MySQL/PostgreSQL 协议，无连接池、事务透传或健康检查能力；它仅能作为 HTTP 网关间接优化数据库访问，如代理 REST API、限流鉴权、HTTPS 终结和连接复用。

nginx 本身不直接连接或代理数据库（如 MySQL、PostgreSQL），它没有内置的数据库协议支持，也不能像反向代理 HTTP 服务那样“转发” SQL 请求。所谓“Nginx 利用异步非阻塞特性优化数据库代理转发”，本质上是一种常见误解或概念混淆。

nginx 不是数据库代理

nginx 的异步非阻塞模型专为高并发 HTTP/HTTPS 流量设计，其事件驱动机制（epoll/kqueue）高效处理大量短连接、静态资源、负载均衡和 TLS 卸载等场景。但：

• 它不解析 MySQL 协议（含握手、认证、命令帧、二进制包长度等）
• 不理解 PostgreSQL 的 startup message、SSL request 或 query-response cycle
• 无法做数据库连接池、事务透传、查询路由或读写分离

真正可行的数据库前置方案

若目标是提升数据库访问性能与并发能力，应选择语义匹配的专用组件：

• ProxySQL：支持 MySQL 协议，具备连接池、查询缓存、SQL 路由、故障自动切换，完全异步（基于 epoll），可部署在应用与 DB 之间
• pgBouncer：轻量级 PostgreSQL 连接池，支持 transaction/session 模式，显著降低后端连接开销
• HAProxy：虽非数据库专用，但支持 TCP 层四层代理，可做 PostgreSQL/MySQL 的健康检查、SSL 终结（需配置 ssl verify none）、连接队列控制，配合 keepalive 复用底层连接

nginx 可间接辅助数据库访问的场景

nginx 仍可在数据链路中发挥价值，但角色是“HTTP 网关”，而非“DB 代理”：

• 将 REST/GraphQL API（如用 Node.js、Python FastAPI 编写的数据库封装服务）作为上游，用 nginx 做限流、鉴权、HTTPS 终结、缓存 GET 接口响应
• 通过 ngx_http_upstream_module 配合 keepalive 指令复用到后端 API 服务的连接，减少 HTTP 连接建立开销，间接提升数据库请求吞吐
• 利用 limit_req 控制单位时间请求数，防止突发流量压垮后端数据库服务

为什么硬改 nginx 做 DB 代理不现实

有人尝试用 stream 模块（stream { ... }）做 TCP 透传，例如：

stream {
    upstream db_backend {
        server 10.0.1.5:3306;
    }
    server {
        listen 3307;
        proxy_pass db_backend;
    }
}

这仅实现最基础的 TCP 转发，存在严重问题：

• 无协议感知 → 无法处理 MySQL 认证失败重试、压缩包分片、长连接保活逻辑
• 无连接池 → 每个客户端连接对应一个后端连接，易耗尽 DB 连接数
• 无健康检查 → 后端宕机时仍转发，导致客户端超时
• 不支持 SSL 代理（MySQL 8.0+ 默认 require SSL，nginx stream 无法解密再加密）