Node.js 应用在 Linux 上如何优化数据库连接

在生产环境中跑 Node.js 应用，数据库连接经常是第一个暴露问题的环节。连接数一上来，响应变慢、超时、甚至服务直接挂掉，这些场景相信不少人都遇到过。下面从几个实用角度，聊聊在 Linux 上怎么把这块优化到位。

1. 从连接池开始

这几乎是所有优化动作里见效最快、成本最低的。数据库连接的建立和销毁本身就有开销，频繁创建不仅拖慢应用，还给数据库服务器增加不必要的压力。连接池预先创建好一批连接，应用需要时直接取，用完归还，效率一下就上来了。大多数数据库驱动都内置了连接池支持，以 PostgreSQL 的 pg 模块为例：

const { Pool } = require('pg');
const pool = new Pool({
  user: 'your_user',
  host: 'your_host',
  database: 'your_database',
  password: 'your_password',
  port: 5432,
  max: 20, // 最大连接数
  idleTimeoutMillis: 30000, // 连接空闲多久后关闭
  connectionTimeoutMillis: 2000, // 连接超时
});

关键参数就那么几个：max 控制池子里最多有多少个连接，idleTimeoutMillis 避免空闲连接长期占用资源，connectionTimeoutMillis 防止某个请求一直卡在等待连接上。具体数值要根据应用并发量和数据库承载能力来调，不是越大越好。

2. 数据库参数也得跟着调

光应用层优化还不够，数据库本身的配置也要配合。很多时候默认配置只适合低负载环境，生产环境需要根据硬件资源做调整。

PostgreSQL 下的常见调整：

-- 调整最大连接数
ALTER SYSTEM SET max_connections = 200;
-- 调整共享缓冲区大小
ALTER SYSTEM SET shared_buffers = '25%';
-- 调整工作内存
ALTER SYSTEM SET work_mem = '4MB';
-- 重启数据库服务
sudo systemctl restart postgresql

max_connections 要和连接池的 max 配合，shared_buffers 一般设为物理内存的 25% 左右，work_mem 则根据排序、哈希等操作的复杂度来定。这些参数没有绝对标准，但有一条原则：数据库的配置应当与应用的连接策略形成互补，而不是各自为政。

3. 异步操作是底线

Node.js 是单线程事件循环模型，同步操作一旦阻塞，整个应用都得等着。所以数据库操作必须用异步方式，这是基本功，但也是不少问题的根源。

pool.query('SELECT * FROM users WHERE id = $1', [userId], (err, res) => {
  if (err) {
    console.error(err);
    return;
  }
  console.log(res.rows);
});

使用 async/await 配合 Promise 也是常见做法，但核心逻辑一样：不要阻塞事件循环。

4. 监控让问题可视化

优化做得再好，没有监控也是盲人摸象。数据库的连接数、活跃连接数、等待时间、错误率，这些指标必须实时掌握。PostgreSQL 的 pg_stat_activity 视图就非常有用：

SELECT * FROM pg_stat_activity;

从这个视图里可以看到当前有哪些连接、在做什么操作、运行了多久。如果发现大量连接处于 idle in transaction 状态，那说明事务没有及时提交或回滚，需要去查应用代码了。其他数据库也有类似的系统视图，关键是养成定期查看的习惯。

5. 负载均衡应对高并发

当单库扛不住时，就得考虑水平扩展了。负载均衡器可以把请求分发到多个只读副本或分片，降低单库压力。常见做法是主库负责写，多个从库负责读，通过负载均衡器或者应用层的读写分离逻辑来实现。

6. 缓存：减少数据库访问的最直接手段

很多查询结果其实不需要每次去数据库拿。比如用户信息、配置数据、热门文章列表，这类数据变更频率低，完全可以用 Redis 或 Memcached 缓存起来。

const redis = require('redis');
const client = redis.createClient();
client.on('error', (err) => {
  console.error('Redis error:', err);
});

pool.query('SELECT * FROM users WHERE id = $1', [userId], (err, res) => {
  if (err) {
    console.error(err);
    return;
  }
  if (res.rows.length > 0) {
    client.setex(`user:${userId}`, 3600, JSON.stringify(res.rows[0]));
  } else {
    client.get(`user:${userId}`, (err, data) => {
      if (data) {
        console.log(JSON.parse(data));
      } else {
        // 从数据库查询并存入缓存
        pool.query('SELECT * FROM users WHERE id = $1', [userId], (err, res) => {
          if (err) {
            console.error(err);
            return;
          }
          client.setex(`user:${userId}`, 3600, JSON.stringify(res.rows[0]));
        });
      }
    });
  }
});

这段代码看着有点长，但核心逻辑就是：先查缓存，命中就直接返回；没命中就去数据库查，然后把结果写入缓存，并设置过期时间。缓存策略一定要根据业务特点来设计，比如缓存失效时间、缓存击穿、缓存雪崩的应对方案，都需要提前考虑。

7. 定期维护保持数据库健康

数据库用久了，索引碎片、过期的统计信息、数据分布不均等问题都会浮现。定期执行维护操作，能让优化效果持续生效。

-- 更新统计信息
ANALYZE;
-- 重建索引
REINDEX INDEX your_index_name;

ANALYZE 更新统计信息，让查询优化器做出更准确的执行计划；REINDEX 重建索引，减少碎片。可以结合 cron 任务在低峰期自动执行。

这几方面结合起来，数据库连接的性能和稳定性基本就能上一个台阶。优化数据库连接从来不是单点问题，需要从应用层、数据库层、基础设施层综合考虑。而且每个环节都有更深的细节，比如连接池的大小怎么精确计算、缓存策略怎么设计更合理，每个点都值得单独展开。先把这些基础框架搭好，后面遇到具体问题再针对性深挖，效率会高很多。