1. Node.js数据库基础：为什么选择Node.js操作数据库

说实话，我刚开始用Node.js做数据库开发时，心里也犯过嘀咕。一个单线程、事件驱动的运行时，真能扛住数据库操作这种重活？后来在几个生产项目里摸爬滚打了一圈，我才彻底服气。

Node.js操作数据库的核心优势，说白了就三点：

  • 非阻塞I/O：数据库查询是典型的I/O密集型操作。Node.js的事件循环机制，让你在等待数据库返回结果时，CPU还能去处理别的请求。我曾在同一个服务器上，用Node.js和Python分别跑同样的查询压力测试，Node.js的并发处理能力明显高出一截。
  • 全栈JavaScript：前后端都用JS，数据模型可以复用。比如你定义了一个User对象，前端校验、后端处理、数据库映射，全用同一套结构。我习惯把数据模型单独抽成一个包，npm一装，哪都能用。
  • 生态丰富：npm上随便一搜，数据库驱动、ORM、查询构建器，应有尽有。你几乎找不到一个主流数据库，在Node.js里没有对应的成熟方案。

核心观点：Node.js不是万能的，但在数据库操作这个场景下，它的异步模型和JavaScript生态，确实能让你写出更简洁、更高并发的代码。

Node.js数据库生态概览

Node.js的数据库生态，我把它分成三个层次。你想想看，从底层到高层，选择越来越方便，但灵活性也越来越低。

第一层：原生驱动

这是最底层的方式。直接使用数据库官方或社区提供的驱动包，比如mysql2、pg（PostgreSQL）、mongodb。你写的是原生SQL或MongoDB查询语句，控制力最强，但代码量也最大。

// 使用 mysql2 原生驱动
const mysql = require('mysql2/promise');

async function getUser(id) {
  const connection = await mysql.createConnection({
    host: 'localhost',
    user: 'root',
    database: 'test'
  });
  const [rows] = await connection.execute('SELECT * FROM users WHERE id = ?', [id]);
  await connection.end();
  return rows[0];
}

我的习惯：如果项目简单，或者对SQL有极致性能要求，我会用原生驱动。但大多数情况下，我建议你至少用个查询构建器。

第二层：查询构建器

像knex.js这样的工具，让你用JavaScript方法链来构建SQL。它不替你管理对象映射，但帮你省去了拼接字符串的麻烦。

// 使用 knex.js 查询构建器
const knex = require('knex')({
  client: 'mysql2',
  connection: {
    host: 'localhost',
    user: 'root',
    database: 'test'
  }
});

async function getActiveUsers() {
  return await knex('users')
    .where('status', 'active')
    .orderBy('created_at', 'desc')
    .limit(10);
}

嗯，这里要注意：查询构建器最大的好处是防止SQL注入。它自动帮你做参数化查询，你不需要手动转义。我曾经见过一个项目，直接用字符串拼接SQL，结果被注入了删库语句……从那以后，我再也不敢手写裸SQL了。

第三层：ORM（对象关系映射）

这是最高层的抽象。像Sequelize、TypeORM、Prisma、Mongoose（MongoDB），它们把数据库表映射成JavaScript类或对象。你操作的是对象，不是SQL。

// 使用 Sequelize ORM
const { Sequelize, DataTypes } = require('sequelize');
const sequelize = new Sequelize('mysql://root:@localhost:3306/test');

const User = sequelize.define('User', {
  name: { type: DataTypes.STRING, allowNull: false },
  email: { type: DataTypes.STRING, unique: true }
});

// 查询就像操作对象一样
async function findUser(email) {
  return await User.findOne({ where: { email } });
}

避坑指南：ORM虽然方便，但别滥用。我曾经接手过一个项目，ORM生成的SQL极其低效，一个简单的联表查询跑了5秒。后来我改成手写SQL，优化到200毫秒。ORM适合80%的常规操作，剩下20%的性能敏感场景，该用原生SQL就用原生SQL。

关系型与非关系型数据库对比

这个选择题，几乎每个Node.js开发者都会遇到。我个人的经验是：没有银弹，只有适合。

维度 关系型数据库（MySQL、PostgreSQL） 非关系型数据库（MongoDB、Redis）
数据模型 结构化，表+行+列，Schema严格 灵活，文档/键值/图，Schema自由
查询方式 SQL，功能强大，支持复杂联表 API查询，简单直接，但复杂查询较弱
事务支持 ACID事务，强一致性 多数支持有限，最终一致性为主
扩展方式 垂直扩展为主，水平扩展较复杂 天然支持水平扩展，分片容易
典型场景 金融、电商、ERP等需要强一致性的系统 日志、社交、实时数据、内容管理
Node.js生态 mysql2、pg、Sequelize、TypeORM mongoose、redis、ioredis

为什么会这样？说白了，关系型数据库把数据一致性放在第一位，而非关系型数据库把灵活性和扩展性放在第一位。你想想看，银行转账少了一分钱，和朋友圈点赞少了一个，哪个更严重？

我的选择策略：

  • 如果数据结构稳定、需要复杂查询和事务 → 选关系型（MySQL/PostgreSQL）
  • 如果数据结构多变、需要快速迭代、数据量大 → 选非关系型（MongoDB）
  • 如果做缓存、会话管理、消息队列 → 选Redis
  • 很多项目其实是混合使用：核心业务用关系型，日志和缓存用非关系型

我记得有个项目，一开始全用MongoDB，后来发现订单和库存之间的关联查询越来越复杂，MongoDB的聚合管道写得像天书。最后我们拆分了：订单和库存用MySQL，用户行为日志继续用MongoDB。嗯，这个架构一直跑到现在，很稳。

给新手的建议：如果你刚开始学Node.js数据库操作，我建议你先从关系型数据库+查询构建器入手。比如MySQL + knex.js。这样你既能理解SQL的本质，又不会被ORM的黑魔法迷惑。等熟悉了底层原理，再上ORM也不迟。

好了，这一章我们聊了为什么Node.js适合操作数据库，看了从原生驱动到ORM的生态全貌，也对比了关系型和非关系型数据库的取舍。下一章，我会带你手把手搭建一个真实的数据库连接池，讲讲那些文档里不会写的坑。

← 上一章 📖 返回目录 下一章 →