数据库操作是绝大多数 Web 应用的性能瓶颈所在。即使 Node.js 本身的事件循环能够高效处理并发，一旦数据库访问变得缓慢，整个服务的吞吐量和响应时间就会直接受到拖累。本节聚焦于三个直接影响数据库性能的核心方面：索引设计、连接池管理以及查询优化，所有建议均基于 Node.js 与常见数据库（MySQL、PostgreSQL、MongoDB 等）结合使用的实战经验。
20.3.1 数据库索引：让数据检索从“翻全书”变为“查目录”
没有索引的数据库查询就相当于在一本没有目录的书里逐页翻找目标段落，数据量一大，查询时间会线性乃至指数级增长。索引的本质是预先建立的数据结构（通常是 B+Tree 或哈希表），让数据库能够以极少量的磁盘 I/O 快速定位目标行。
索引不是越多越好
很多初级开发者误以为“每个查询字段加一个索引”就能解决所有性能问题，但索引本身是有代价的：
- 写操作变慢：每次 INSERT、UPDATE、DELETE 都需要同时维护索引结构，索引过多会让写入性能严重下降。
- 占用额外磁盘与内存空间：索引自身也是数据，大量索引会显著增加数据库的存储成本和缓存压力。
- 查询优化器可能选错索引：当多个索引存在时，数据库需要判断使用哪一个，判断失误反而导致性能变差。
因此，只为确实出现在 WHERE、JOIN、ORDER BY 中的高频字段创建索引，并且定期结合慢查询日志分析哪些查询真正需要索引。
联合索引与单列索引的选择
在实际业务中，多个条件同时出现的查询非常常见，例如“查询某用户在某时间段内的订单”。此时如果为 user_id 和 created_at 各建一个单列索引，数据库通常只能利用其中一个，另一个条件依然需要扫描大量行。更优的方案是建立 联合索引 (user_id, created_at)，让数据库在一次索引查找中同时过滤两个条件。
联合索引有一个重要的最左前缀原则：(A, B) 索引可以服务 WHERE A = ? 和 WHERE A = ? AND B = ? 的查询，但无法高效服务单独的 WHERE B = ?。所以在设计联合索引时，应把区分度高或经常单独出现的字段放在最左边。
索引与 Node.js 的结合实践
在 Node.js 中，使用 ORM（如 Sequelize、TypeORM、Prisma）时，索引通常通过模型声明或迁移文件创建。
Sequelize 示例：
const Order = sequelize.define('Order', {
userId: { type: DataTypes.INTEGER },
createdAt: { type: DataTypes.DATE }
}, {
indexes: [
{ fields: ['userId', 'createdAt'] } // 联合索引
]
});Prisma 示例：
model Order {
id Int @id @default(autoincrement())
userId Int
createdAt DateTime
@@index([userId, createdAt])
}无论使用 ORM 还是原生 SQL，定期使用 EXPLAIN 或 EXPLAIN ANALYZE 查看查询计划，确认索引是否被使用、扫描行数是否合理。例如在 MySQL 中：
EXPLAIN SELECT * FROM orders WHERE userId = 100 AND createdAt > '2024-01-01';注意 key 列是否显示你期望的索引名，rows 列是否远小于表总行数。如果 type 为 ALL（全表扫描），说明索引未生效，需要排查字段类型、函数使用、字符集等细节。
20.3.2 连接池：复用连接，避免频繁握手
数据库连接的建立成本很高，包括 TCP 三次握手、数据库身份认证、会话初始化等。如果每次查询都新建连接、用完关闭，不仅延迟激增，数据库本身也会因为频繁的上下文切换而耗尽资源。
连接池在服务启动时预先创建一定数量的连接，这些连接被所有请求复用。当某次查询需要连接时，从池中取出一个空闲连接，用完归还，从而避免了频繁创建销毁的开销。
连接池的核心配置参数
不同数据库驱动的连接池参数略有不同，但均包含几个关键数值：
- 最大连接数（max）：池中允许的最大连接数量，也是数据库同时处理请求的上限。设置太大会让数据库超负荷，太小则会导致请求排队等待连接。
- 最小连接数（min）：池始终保持的空闲连接数，避免突发请求时产生冷启动延迟。
- 空闲超时（idleTimeout）：空闲连接保持的最长时间，超过后自动释放，防止无用的连接占用数据库资源。
- 获取连接超时（acquireTimeout）：当池中无空闲连接时，等待连接释放的最大时间，超时后抛出错误。
以流行的 mysql2 驱动为例：
const mysql = require('mysql2/promise');
const pool = mysql.createPool({
host: 'localhost',
user: 'root',
database: 'app',
connectionLimit: 10, // 最大连接数
waitForConnections: true, // 是否等待空闲连接
queueLimit: 0 // 排队请求上限，0 表示无上限
});连接池大小的经验计算
没有万能公式，但可以根据数据库所能支持的最大连接数与 Node.js 进程数来推算。例如，数据库最大连接数是 200，你有 4 个 Node.js 进程（或集群节点），那么每个进程的连接池上限设为 200 / 4 = 50 是一个安全起点。但实际仍需结合压测动态调整。
对于 MongoDB + Mongoose，其默认的 poolSize 为 5，通常适用于中小应用，对于高并发场景可以适当增大。对于 Prisma，连接池由内部的 connection_limit 参数控制，默认值基于 CPU 核心数动态计算。
连接池的常见陷阱
- 连接泄漏：在原生回调式的数据库操作中，如果忘记归还连接（
connection.release()未调用），连接会一直被占用，最终池枯竭。使用async/await和连接池包装函数能极大避免此问题。 - 事务与连接绑定：事务必须在同一个连接上执行，如果事务期间连接被其他操作获取，会导致混乱。Node.js 的许多 ORM 通过事务接口自动帮你绑定连接，但仍需注意事务内部不要混用不同连接。
- 超时设置不合理：
acquireTimeout过短会导致流量高峰时大量请求因获取连接失败而报错，过长又会造成请求堆积。应结合业务可接受的等待时长来设定，并配合熔断降级机制。
在真实项目中，还应通过监控连接池状态（如 pool._allConnections.length、pool._freeConnections.length），结合 Prometheus 等工具暴露指标，及早发现连接池压力。大部分 ORM 和驱动都提供了事件监听，例如 pool.on('error', console.error) 可以捕获连接层异常。
20.3.3 查询优化：写出让数据库“心领神会”的 SQL
索引只是物理层面的加速，查询逻辑本身不合理同样会导致性能灾难。Node.js 中的查询优化主要关注两大方面：SQL 语句的高效书写，以及 ORM 的合理使用。
避免 N+1 查询
N+1 查询是最常见的性能杀手。例如，先查询用户列表，然后循环对每个用户发起查询获取其订单：
// 错误示例：N+1 查询
const users = await db.query('SELECT * FROM users');
for (const user of users) {
const orders = await db.query('SELECT * FROM orders WHERE userId = ?', [user.id]);
// ...
}这会把一次查询变成 1 + N 次数据库交互，每个查询都经过网络往返和数据库处理。优化方式为使用 JOIN 或一次查询获取所有关联数据：
// 优化：使用 IN 子句批量查询
const userIds = users.map(u => u.id);
const orders = await db.query('SELECT * FROM orders WHERE userId IN (?)', [userIds]);
// 再在应用层分组映射ORM 通常提供“饥饿加载”功能来避免 N+1。Sequelize 中可用 include，Prisma 中可用 include 或 select，Entity Framework 式的懒加载要慎用。
Prisma 示例：
const usersWithOrders = await prisma.user.findMany({
include: { orders: true } // 一次性查询关联数据
});只查询需要的字段
SELECT * 会返回所有列，如果表中包含较大的 TEXT 或 BLOB 字段，网络传输和内存占用都会剧增，且无法利用覆盖索引（覆盖索引可直接从索引返回数据，不需回表）。明确指定字段列：
// 不推荐
const users = await db.query('SELECT * FROM users WHERE status = ?', ['active']);
// 推荐：只取必要字段
const users = await db.query('SELECT id, name, email FROM users WHERE status = ?', ['active']);在 ORM 中，Prisma 的 select、Sequelize 的 attributes 参数均能达到相同效果。
分页与避免大偏移量
LIMIT 1000 OFFSET 100000 会导致数据库扫描前 100000 行后再丢弃，速度极慢。当偏移量很大时，更高效的做法是使用“游标分页”（基于主键或时间戳）：
-- 传统分页（慢）
SELECT * FROM orders ORDER BY id LIMIT 20 OFFSET 100000;
-- 游标分页（快）
SELECT * FROM orders WHERE id > 100000 ORDER BY id LIMIT 20;Node.js 中可以直接用 where 和 cursor 参数配合 ORM 实现。注意游标分页要求排序字段与游标字段一致且唯一递增。
合理使用原生查询
ORM 生成的 SQL 不一定最优，特别是复杂报表、多表联查、聚合操作。当 ORM 表现不佳时，应果断使用原生 SQL，并借助参数化查询防止注入：
const [rows] = await sequelize.query(
'SELECT u.name, SUM(o.amount) as total FROM users u JOIN orders o ON u.id = o.userId GROUP BY u.id',
{ replacements: {} }
);Prisma 同样支持 $queryRaw 方法。不要为了“纯 ORM”而牺牲性能和代码可读性。
查询缓存与读写分离
对于频繁读取但极少更新的数据（如配置表、地区列表），可以在 Node.js 应用层增加内存缓存或 Redis 缓存，避免重复数据库查询。常用模式是“先读缓存，未命中再查库，并写入缓存”。同时，对于读多写少的主从架构，将查询路由到只读从库，也能有效分担主库压力。Node.js 数据库驱动或 ORM 一般都支持多实例连接，可以通过简单的逻辑实现读写分离。
20.3.4 监控与持续优化
优化不是一劳永逸的，随着数据量和访问模式的变化，原本高效的查询可能逐渐变慢。Node.js 项目应集成慢查询日志（如 MySQL 的 slow_query_log），并定期分析。此外，应用层面的 APM 工具（如 Elastic APM、New Relic、OpenTelemetry）能记录每个数据库查询的耗时，帮助快速定位问题。
在代码层面，利用 console.time 或性能测量 API 包装查询函数，在非生产环境输出平均耗时，也是一种轻量的自检手段。
小结：数据库优化围绕“减少 I/O 次数”和“减少数据扫描量”两个核心目标展开。索引让数据库快速定位目标行，连接池减少连接建立开销，而优秀的查询写法则直接决定了 I/O 的效率。在 Node.js 的高并发环境下，这三个环节的任何短板都可能被放大，因此它们是性能优化不可或缺的组成部分。