浏览器里敲下回车，连接页面弹出来，数据数据从哪儿来？连接十有八九，它藏在一台数据库服务器里。数据Web应用本身不会“凭空”知道你的连接订单记录、用户资料，数据它得主动去问数据库要。连接这个过程，数据就是连接Web连接数据库。

拿一个最典型的数据场景说：你登录某电商网站，输入手机号和密码，连接点击登录。数据前端把数据打包发给后端服务器，连接后端代码——比如用Node.js、数据Python或者Java写的连接——拿到这串请求后，立刻转身去连数据库。连上之后，执行一句类似 SELECT * FROM users WHERE phone = '138xxxx' 的查询，数据库把匹配的记录扔回来，后端再比对密码，决定放不放你进去。

那“连接”具体怎么发生？以MySQL为例，后端代码里通常会有一个连接字符串，长得像 mysql://user:password@host:3306/dbname。这里面包含了数据库地址、端口、用户名、密码、库名。代码通过驱动（比如Node.js里的 mysql2，Python里的 pymysql）向这个地址发起TCP连接。数据库验证身份后，建立一条会话通道。之后所有SQL语句都通过这条通道来回跑。

但这里有个坑。每次用户请求都新建一条数据库连接，开销很大——TCP三次握手、数据库认证、分配资源，一套下来几十毫秒没了。高并发时数据库直接被打爆。所以实际项目里几乎不会这么干，而是用连接池。连接池预先建好一批连接，放在那儿待命。请求来了，从池子里借一条，用完还回去，不销毁。Node.js里用 mysql2/promise 的 createPool，Java里用HikariCP，都是这个思路。池子大小要调，太小排队，太大数据库扛不住。我见过一个项目连接池设成500，结果数据库最大连接数才200，直接报错。这种细节，文档里往往不显眼，但线上出事就是大事。

再往下走，连接建立后，SQL怎么执行？简单查询直接 connection.query() 就完事。但如果你把用户输入拼进SQL字符串，比如 "SELECT * FROM users WHERE name = '" + userName + "'"，那就等着被注入吧。用户输入 ' OR '1'='1，整个表的数据全泄了。正确做法是参数化查询：connection.query('SELECT * FROM users WHERE name = ?', [userName])。驱动会把参数安全地转义，和SQL语句分开传输。这是铁律，没有例外。

还有一种情况：Web应用和数据库不在同一台机器。中间隔着网络，甚至跨机房。这时候连接延迟会明显上升。我实测过，同机房内网连接一次约0.5毫秒，跨公网可能到30毫秒以上。如果一次请求要查十几次数据库，累积延迟就非常可观。解决办法要么是把数据库拉近，要么用缓存挡一层，要么把多次查询合并成一次。没有银弹，看业务取舍。

另外，数据库连接不是永久的。网络抖动、数据库重启、空闲超时，都会让连接断掉。连接池一般会配置 idleTimeout 和 connectionTimeout，空闲太久就回收，借出太久没还就强制断开。但代码里还得处理断线重连。比如MySQL驱动有个 waitForConnections 和 queueLimit，队列满了直接拒绝，避免请求无限堆积。这些参数调优，靠的是对业务流量峰值的理解，不是抄个默认值就完事。

最后提一句NoSQL。MongoDB、Redis这类，连接方式和MySQL类似，但协议不同。Redis用RESP协议，MongoDB用BSON over TCP。连接池概念一样存在，比如Redis的 ioredis 自带连接池。选哪种数据库，取决于数据结构——关系型适合事务和复杂查询，文档型适合灵活字段，键值型适合高速缓存。Web连接它们的方式，本质都是：驱动 + 连接字符串 + 池化 + 参数化查询。把这四件事做对，基本不会出大乱子。

(责任编辑：知识)