Sequelize实战指南：Node.js项目从选型到生产环境踩坑全解析

三年前我接手一个Node.js老项目，高峰期接口平均响应300ms，慢接口能去到两秒以上。排查了大半天，发现罪魁祸首不在业务代码，而在数据访问层——几百条裸SQL散落在各个service文件里，有的连表关系都写错了却没人敢动，因为谁也不知道改动会影响哪块业务。从那时候起，我开始认真思考ORM的选型问题，在Node.js生态里对比了几套方案之后，最终落地用的是Sequelize。

这篇文章不是官方文档的搬运工，而是把我在真实项目里从选型、建模、关联查询到生产环境踩坑的完整路径拆给大家看。无论你是刚入门Node.js的初学者，还是已经被裸SQL折磨过一阵子的开发，只要能跟着把这几大部分过一遍，回到自己项目里就能直接抄作业用起来。

1. 选型对比与前置准备：为什么我把Sequelize留在后端项目里

1.1 为什么不是TypeORM、Prisma或Knex

先聊聊选型。Node.js生态里ORM和查询构建器不少，我用过或评估过TypeORM、Prisma、Knex和Sequelize。很多人一上来就问“哪个最好”，我的观点是：没有最好，只有最契合你的团队和项目维护方式。

TypeORM的TypeScript友好度确实高，装饰器写模型很爽，但如果你用了不少高级特性，它的类型定义和版本升级之间经常出现断裂。我在一个中型项目里遇到过两次小版本升级后查询行为变化的问题，排查成本不低。Prisma是另一种思路，它用schema文件描述数据模型，会自己生成客户端，开发体验和类型提示确实现代，但在动态查询、复杂关联和既有数据库迁移场景下，灵活度反而受限，而且它多了一层引擎，团队内部需要多学习一个心智。Knex本质上是query builder，比裸SQL好维护，但它不管模型映射，表结构和对象之间还得自己再套一层DAO层。

Sequelize能留下来的核心原因有三条：第一，成熟稳定，v6已经打磨了很多年，遇到问题全网都能搜到解决方案，这一点在出线上故障时太重要了；第二，同时支持MySQL、PostgreSQL、SQLite、MSSQL，对需要切换数据库的项目很重要；第三，迁移（Migration）机制完整，配合sequelize-cli可以像管理代码一样管理表结构变更。这三个特点对一个长期维护的业务系统来说，都是实打实的加分项。

放一张我当时整理的对比表，供大家参考：

我没有否定其他框架的意思，如果你是新项目、并且整个团队愿意拥抱Prisma的建模方式，Prisma也很优秀。但如果你想找一个文档全、上手快、社区问题积累多、坑都能查得到的ORM，Sequelize是更稳妥的起点。

1.2 环境准备：版本选择与安装清单

选定了框架，先把环境搭好。我用的是Node.js 18 LTS，Sequelize v6.x。v7也在持续迭代，但考虑到很多云函数、CI镜像还停留在v6，这篇文章全部以v6为主。如果你用的是v7，核心概念一致，只是一些初始化参数的写法有变化。

安装步骤很简单，项目根目录执行：

npm install sequelize@6 sequelize-cli

然后按数据库型号装对应驱动。用MySQL装mysql2，用PostgreSQL装pg，用SQLite装sqlite3，用SQL Server装tedious。我默认以MySQL为例，因为国内中小团队和云数据库最常见的就是它：

npm install mysql2

注意一点：MySQL驱动建议直接用mysql2而不是老旧的mysql包，因为mysql包对密码认证方式的支持不够好，在caching_sha2_password协议下容易报错，mysql2没这个问题，而且默认支持prepared statement，性能更好。

装完后推荐在package.json里加几个脚本，后面都会用到：

{ "scripts": { "db:migrate": "sequelize-cli db:migrate", "db:seed": "sequelize-cli db:seed:all", "db:rollback": "sequelize-cli db:migrate:undo" } }

这样部署上线跑迁移的时候，直接npm run db:migrate就行了，不用记一堆npx命令。团队里新人也容易上手。

2. 项目初始化与连接配置：从npm init到数据库连通

2.1 sequelize-cli初始化的正确姿势

Sequelize官方提供的CLI能帮你把目录骨架搭起来。在项目根目录执行：

npx sequelize-cli init

它会生成四个目录：config（配置文件）、models（模型定义）、migrations（迁移文件）、seeders（种子数据）。这个约定俗成的目录结构建议保留，尤其团队协作时，新同事看到就能知道东西在哪。

初始化生成的config/config.js默认长这样（新版本CLI生成的是config.js，老版本可能是config.json）：

{ "development": { "username": "root", "password": null, "database": "database_development", "host": "127.0.0.1", "dialect": "mysql" } }

这里有个很多人第一次用会踩的坑：如果只改了dialect为mysql，而没有安装mysql2，启动时会报“Please install mysql2 package manually”。报错信息已经写得很直白了，但容易忽略的是，装了mysql2之后如果你的项目里有多个环境变量，需要确认config里的配置能被正确读取，否则后面部署到测试环境时，连接的可能还是本地库。

我自己的习惯是把这些数据库配置放到环境变量里，config文件改成导出一个函数，运行时动态读取：

require('dotenv').config(); module.exports = { development: { username: process.env.DB_USERNAME, password: process.env.DB_PASSWORD, database: process.env.DB_NAME, host: process.env.DB_HOST, dialect: 'mysql' }, test: { // 测试库配置 }, production: { // 生产库配置，通常走环境变量 } };

这样配置文件里不出现明文密码，多环境切换也方便。千万不要把数据库密码直接提交到git仓库，尤其是生产库的密码，这条红线任何规模的项目都适用。

2.2 连接池、时区与字符集的配置清单

数据库连接不是简单new一个实例就行，生产环境里连接池、时区、字符集这三个配置直接影响稳定性。

先看连接池。MySQL默认最大连接数是151，如果应用并发上去了，每个请求都新建连接，数据库很快就扛不住。Sequelize的配置里可以指定pool：

const sequelize = new Sequelize(config.database, config.username, config.password, { host: config.host, dialect: 'mysql', pool: { max: 20, min: 5, acquire: 30000, idle: 10000, evict: 1000 } });

max和min是连接池里最大最小连接数，acquire是获取连接的超时时间（毫秒），idle是连接空闲多久之后释放。这里有一个经验值：max不要超过数据库max_connections的30%，否则多个应用实例共享一个库时，连接数直接被打满。

再看时区。这是项目里最容易出现“灵异时间”的地方。如果数据库存的是北京时间，Node服务跑在UTC时区，查询出来的时间就会差8小时。建议在配置里显式声明：

timezone: '+08:00'

同时，MySQL连接也要在dialectOptions里设置dateStrings为true，确保时间字段以字符串形式返回，以避免JS的Date对象在序列化时再转一次时区：

dialectOptions: { dateStrings: true, typeCast: true }

timezone和dateStrings这两个配置组合起来，能解决大部分“数据库中是对的，接口返回就变了”的问题。

最后是字符集。建库时如果没有统一utf8mb4，中文和emoji会出现乱码。我在初始化数据库连接时，会在语句里显式指定：

CREATE DATABASE IF NOT EXISTS your_db DEFAULT CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;

表结构里的字符串字段也建议对应使用utf8mb4。这一步虽然看起来不是Sequelize的职责，但连接配置里的charset没对齐，某些字符照样会被静默截断或乱码。

连接配好之后，可以用一段代码验证连通性：

const sequelize = new Sequelize(...); async function checkConnection() { try { await sequelize.authenticate(); console.log('数据库连接正常'); } catch (error) { console.error('数据库连接失败:', error); } }

authenticate不会执行任何业务SQL，只是发一条SELECT 1之类的探活语句。依赖它作为服务启动时的健康检查，比等到第一个请求时才暴露问题要好得多。我一般还会在启动脚本里加一个超时重试的包装，这样数据库在容器编排里晚启动几秒也不会造成应用崩溃。

3. 模型与迁移：代码里的表结构应该怎么定义

3.1 用Model.init还是define定义模型

Sequelize定义模型有两种风格：一种是直接调用sequelize.define，另一种是继承Model类再调用Model.init。两种方式能力等价，但团队协作建议统一风格。我习惯用继承Model的方式，理由是它在复杂模型里可读性更好，也方便在模型里加自定义方法。

先用一个实际例子看定义：

const { Sequelize, DataTypes, Model } = require('sequelize'); const sequelize = require('../models/index'); class User extends Model {} User.init( { id: { type: DataTypes.BIGINT.UNSIGNED, primaryKey: true, autoIncrement: true }, username: { type: DataTypes.STRING(64), allowNull: false, unique: true, comment: '登录名' }, nickname: { type: DataTypes.STRING(64), allowNull: false, defaultValue: '' }, email: { type: DataTypes.STRING(128), validate: { isEmail: true } }, status: { type: DataTypes.TINYINT, allowNull: false, defaultValue: 1, comment: '1-正常 0-禁用' } }, { sequelize, modelName: 'User', tableName: 'users', timestamps: true, underscored: true, paranoid: true, indexes: [ { unique: true, fields: ['email'] } ] } ); module.exports = User;

字段定义是模型的核心，上面的注释、默认值这些细节，会在后续通过迁移生成建表语句时直接落到数据库，别人看表结构就能懂业务意图，强烈建议每个字段都写comment。

选项里的几个参数值得留意：

• timestamps: true，自动帮你维护createdAt和updatedAt两个字段；
• underscored: true，让自动生成的字段名使用下划线风格，比如created_at，和数据库习惯一致；
• paranoid: true，开启软删除，删除记录时不是DELETE，而是更新deletedAt字段。

这三个组合几乎是业务表标配，能省掉大量手写习惯性字段的重复工作。

3.2 字段类型、校验器与默认值的配置细节

选择字段类型有一点容易忽略：Sequelize的DataTypes和MySQL原生的字段类型不是一一对应，很多类型要加上长度或修饰符，建出来的表才符合预期。

比如主键，如果数据量可能超过21亿，用INTEGER就不安全，建议用BIGINT.UNSIGNED；金额字段用DECIMAL(10, 2)而不是FLOAT，避免浮点误差；布尔值在MySQL里没有真正的boolean，TINYINT(1)才是落库后的真实形态；保存JSON配置项，用DataTypes.JSON，查询时可以直接按字段取。

校验器是另一个容易被低估的功能。它是在数据落地前的一层业务校验，比如邮箱格式、年龄范围、字符串长度。注意：validate里的校验只在应用层执行，它依赖的是Sequelize给字段预设的验证规则，如果手写SQL绕过模型插入数据，校验就不会生效。所以它是“辅助防御”，不能替代数据库层约束。

默认值也建议尽量在模型里声明，不要只依赖数据库default。原因很简单，当你用Model.create插入一条记录时，如果模型里没写defaultValue，Sequelize在生成的INSERT语句中就不会带这个字段，虽然数据库层也会兜底，但一旦后续有人改了表结构里的默认值，而模型里没同步，行为就会不一致。统一在模型里写，至少有一个明确的“代码即文档”的效果。

这里还有一个正则校验的常见错误：validate里的isEmail、isInt这些校验器接收的是字符串，undefined和null会跳过校验。如果你希望某个字段必填，需要再配合allowNull: false或者notEmpty规则，否则空字符串也可能被放过。

3.3 迁移：改表结构的正确方式

很多新手在开发阶段为了省事，直接在代码里写sequelize.sync({ alter: true })，让模型和数据库自动同步。开发环境玩玩可以，生产环境千万不要这么做，因为sync的alter是“尽力而为”，它可能因为字段类型不兼容而失败，更危险的是在表数据量大的时候，alter对表加锁可能造成长时间阻塞。

正确的改表方式是用迁移。sequelize-cli生成迁移文件：

npx sequelize-cli migration:generate --name add_status_to_users

生成的文件里up和down两个函数分别描述“怎么改”和“怎么回滚”：

'use strict'; module.exports = { up: async (queryInterface, Sequelize) => { await queryInterface.addColumn('users', 'status', { type: Sequelize.DataTypes.TINYINT, allowNull: false, defaultValue: 1, comment: '1-正常 0-禁用' }); }, down: async (queryInterface) => { await queryInterface.removeColumn('users', 'status'); } };

然后执行：

npx sequelize-cli db:migrate

它会记录每次迁移的执行状态到SequelizeMeta表，后续rollback、再执行都靠这张表做依据。这个机制保证了团队的每个成员或CI上的每次部署，都能按同样的顺序、同样的步骤把表结构推进到目标状态。

我自己还有一个习惯：迁移文件里带好comment，并且每个字段的变更尽量拆成独立的迁移文件，而不是一次大改。原因很简单——线上出问题时，拆得越细，越能精准定位是哪一次迁移引入的问题，回滚也越小。

4. 模型关联与联表查询：include背后的配置细节

4.1 四类关联关系的适用场景

业务系统里最核心的模型能力是关联。Sequelize支持四种关联：hasOne、hasMany、belongsTo、belongsToMany。不少初学者在这里搞混，其实只要记住“站在哪边看关系”就不会错。

直接说结论：外键一定定义在“多”的那一侧。举一个最常见的例子，User和Post，一个用户有多篇文章：

// Post 表里有 user_id 外键 Post.belongsTo(User, { foreignKey: 'userId', as: 'author' }); User.hasMany(Post, { foreignKey: 'userId', as: 'posts' });

belongsTo和hasMany的foreignKey要指向同一个字段，as别名两边保持一致的语义。User侧用posts表示“我有哪些文章”，Post侧用author表示“这篇文章的作者是谁”。

如果是多对多，比如User和Tag，就需要一张中间表：

User.belongsToMany(Tag, { through: 'user_tags', foreignKey: 'userId', otherKey: 'tagId' }); Tag.belongsToMany(User, { through: 'user_tags', foreignKey: 'tagId', otherKey: 'userId' });

through可以传模型名也可以传字符串表名，前者适合中间表还有其他业务字段的情况。比如user_tags表里如果有created_at字段，记录“什么时候打的标签”，那through就必须是一个定义好的模型，否则这些额外字段会被Sequelize忽略。

一对一相对少见，典型的场景是用户资料表user_profiles，主用户表users走hasOne，资料表反向belongsTo。注意此时外键放在资料表，users表本身不加字段。

4.2 include联表查询的别名与作用域

关联配置好后，联表查询靠include实现：

const user = await User.findByPk(1, { include: [ { model: Post, as: 'posts', where: { status: 1 }, required: false, order: [['created_at', 'DESC']], limit: 10 } ] });

include里的几个属性值得展开说：

• model和as对应关联定义，如果关联时定义了别名as，这里必须带上，否则Sequelize不知道你要联哪条关联；
• where用来过滤被关联子表的记录；
• required: false代表LEFT JOIN，也就是说主表记录即使没有匹配的子记录也会返回，子表字段为null；
• required的默认值取决于where有没有写：写了where，默认是true，也就是INNER JOIN，外层的记录会被过滤掉。这是一个非常常见的坑，想查“没有文章的用户”时，需要用required: false再配合where: { id: null }。

include还可以嵌套，文章带评论、评论带作者，三层以内都是很自然的查询粒度。但层级越多，SQL越复杂，性能也越难控制。我在生产项目里会严格控制include的深度，超过两层就考虑拆成多次查询，在应用层组装。ORM虽然能写得很爽，但数据库执行计划里出现范围的扫描时，优化起来比拆查询麻烦很多。

还有一个容易被忽略的坑是：如果include的子表模型也开启了paranoid，联表时Sequelize会自动追加deletedAt IS NULL条件；如果子表本身没有deletedAt字段，但你加了paranoid: false在include里，反而会干扰Sequelize对关联查询的拼接。我建议对业务主干表统一开启paranoid，对纯关联表、配置表不开，避免心智负担。

4.3 软删除与外键约束的关联配置

前面说过paranoid: true开启软删除。但软删除和数据库外键约束之间有个矛盾：如果Post表对users表有外键ON DELETE CASCADE，那么delete一条用户记录时，数据库层会直接物理删除关联文章，软删除就失效了。

实战中我的做法是：数据库外键约束主要用于保证数据一致性，但删除动作交给业务层处理，不在数据库层做CASCADE物理删除。业务代码里要删用户，就手动把用户标记为deleted，再批量把其文章标记为deleted，或者按业务决定是否同时软删。这样既保留了外键约束的完整性校验，又不会破坏软删除的审计链路。

另外注意，软删除开启后，默认的查询都会自动带上deletedAt IS NULL。但如果你用了include，且被联表模型也开启了paranoid，Sequelize会自动给子表也加deleted条件；如果被联表模型没有开启paranoid，而你想从带deleted的记录里查数据，就要在include里显式加上paranoid: false。这些都藏在细节里，等到线上数据对不上时才排查就晚了。

5. 高级查询与事务：日常CRUD之外的实战场景

5.1 常用查询操作速查

先上一段组织好的速查，覆盖最常用的查询场景。

// 基础查询 await User.findByPk(id); await User.findOne({ where: { email } }); await User.findAll({ where: { status: 1 } }); // 计数与分页 const { count, rows } = await User.findAndCountAll({ where: { status: 1 }, offset: 20, limit: 10, order: [['id', 'DESC']] }); // 条件操作符 const { Op } = require('sequelize'); await User.findAll({ where: { age: { [Op.gte]: 18 }, name: { [Op.like]: '%张%' }, status: { [Op.in]: [1, 2] }, createdAt: { [Op.between]: [start, end] } } });

findAndCountAll返回一个{ count, rows }对象，count是满足条件的总记录数，rows是当前页数据。注意count在include子表关联并且子表有where时会变成数组或带区分的结果，需要distinct处理，我在6.1里会说。

除了以上这些，还有几个我经常用到的操作：

// 存在则返回，不存在则创建，适合登录账号初始化 const [user, created] = await User.findOrCreate({ where: { username: 'zhang' }, defaults: { nickname: '张三', email: 'zhang@example.com' } }); // 数值增减，比先查后更新更安全 await User.increment('score', { by: 5, where: { id: userId } }); // 指定字段查询，少带不需要的大字段 await User.findAll({ where: { status: 1 }, attributes: ['id', 'username', 'nickname'] });

attributes的字段筛选在列表接口里很实用，只返回需要的列，既减小网络传输，也避免把密码、内部备注之类的敏感字段暴露出去。

还有一个隐藏功能：attributes可以配合Sequelize.fn做聚合。比如统计每个用户的文章数，不需要写RAW SQL：

const stats = await Post.findAll({ attributes: [ 'userId', [Sequelize.fn('COUNT', Sequelize.col('id')), 'postCount'] ], group: ['userId'] });

这种方式生成的SQL可控，也保留了模型层的参数绑定能力，推荐优先使用。

5.2 事务：手动事务与Managed Transaction

事务是保证数据一致性的底线。最推荐的方式是用Sequelize的managed transaction，它帮你自动commit和rollback：

try { const result = await sequelize.transaction(async (t) => { const user = await User.create({ ... }, { transaction: t }); await Post.create({ userId: user.id, title: '...' }, { transaction: t }); return user; }); } catch (error) { // 这里的事务已自动回滚，无需手写rollback }

在transaction()的回调里，所有SQL操作都要把transaction对象t传给参数options.transaction，漏了任何一个，那条操作就会在事务外执行。这是最容易出错的地方，尤其是多层函数调用时，需要把t一路传下去。为此我习惯把事务对象挂到上下文里，或者使用CLS（Continuation Local Storage）方案，Sequelize官方文档里也有介绍，不过对于团队新手来说，显式传参更直观。

如果是多个实例并发操作同一行数据，建议配合悲观锁或版本号乐观锁。Sequelize里可以用lock: true拿到行锁，比如扣库存场景：

const item = await Item.findOne({ where: { id: goodsId }, lock: t.LOCK.UPDATE, transaction: t });

注意lock: t.LOCK.UPDATE依赖外层有事务t，否则Sequelize不会加锁。很多人在Java里用过带for update的写法，在Sequelize里就是lock参数。

事务使用频率最高的场景是：写主表、写子表、更新余额、写流水，任何一个环节失败都要整体回滚。如果发现代码里散落着大量手动commit/rollback，建议统一收敛到managed transaction封装，让业务代码只关心自己的逻辑，事务边界由封装层管理，能减少一半事务相关的线上故障。

5.3 批量操作与性能优化

业务上经常遇到“导出全部”“批量导入”这类场景，能上批量就别用循环单条操作。

await User.bulkCreate(userList, { validate: true, ignoreDuplicates: true, updateOnDuplicate: ['nickname', 'email'] });

bulkCreate默认不做字段校验，如果数据量不大且需要校验，设置validate: true；如果表里有唯一键，ignoreDuplicates: true可以跳过重复数据；updateOnDuplicate配合唯一键，可以做到MySQL的upsert效果——存在就更新，不存在就插入。

批量更新也类似，用where锁定目标范围：

await User.update( { status: 0 }, { where: { lastLoginAt: { [Op.lt]: oneYearAgo } } } );

批量删除：

await User.destroy({ where: { status: 0 } });

高并发下还有一个经验：批量操作一次不要塞太多条，我一般控制在500到1000条一批，超过就分块循环。数据库单条INSERT和批量INSERT性能差很多，但量级过大时，单条SQL字符串过长，MySQL的max_allowed_packet会报错。分批执行是一个稳妥的策略。

另外，批量数据里如果有重复的唯一键，bulkCreate会抛错，但如果业务上希望“忽略重复继续插入”，ignoreDuplicates: true是个好开关。如果你的数据库是PostgreSQL，这个参数会生成ON CONFLICT DO NOTHING，行为等价。

6. 生产环境复盘：我在Sequelize上踩过的坑和排查方法

6.1 N+1查询：慢查询的头号原因

N+1问题几乎每个ORM使用者都会遇到。症状很典型：接口响应越来越慢，数据库慢查询日志里刷出来一堆结构相似的SELECT，每条就差主键值不同。原因也简单，在循环里做了单条查询。

const users = await User.findAll(); for (const user of users) { const posts = await Post.findAll({ where: { userId: user.id } }); // ... }

users有1000条，就多出1000次查询。ORM虽然把查询写进了代码里，但如果你在循环里逐个查，它也没法替你优化。解决办法是用include一次联出来，或者用where in批量查：

const users = await User.findAll({ include: [{ model: Post, as: 'posts' }] });

查询次数从1001次降到1次。排查N+1的方法也很直接：打开Sequelize的SQL日志，或者用数据库的general_log和slow_query_log，看到大量相似语句基本就是它。

我踩过最深的一个坑是关联里再套关联，比如查用户列表、带上每篇文章、再带上每篇文章的评论，如果每层都单独查询，总查询次数会是N*M级别的爆炸。这种场景除了控制include层级，没有别的银弹，必要时就拆成两三次大查询，在内存里组装。

6.2 时间与数字类型踩坑

时间字段是Sequelize项目里出问题最多的地方。我曾经遇到过一个签到模块，记录在数据库里是对的，但接口返回给前端时时间全部少了8小时。查了半天发现，数据库连接时区没设置，Node进程又跑在UTC时间，JS Date对象在JSON序列化时自动转回了UTC，于是时间就偏了。

解决办法就是我2.2里说的，把timezone和dateStrings配置好。dateStrings: true让Sequelize在读取DATETIME字段时直接返回字符串，不转成Date对象，从而绕开时区转换问题。代价是后续在JS里手动处理时间运算，但大多数业务只是展示，字符串反而更稳。

数字类型也有坑。默认的INTEGER会截断超过21亿的值；DataTypes.DECIMAL如果不用字符串读取，JS浮点运算会出现0.1 + 0.2不等于0.3的问题。金额相关字段建议DECIMAL和字符串模式，我一般会在项目里统一配置decimalNumbers: false，让DECIMAL以字符串返回，再在应用层转，绝对不要直接做浮点运算。

还有无符号数的坑：MySQL的INT UNSIGNED，在Sequelize里要用DataTypes.INTEGER.UNSIGNED显式声明。如果不声明，生成字段时默认是带符号的，比如自增主键到21亿以上就会报错。BIGINT.UNSIGNED同理，尤其是在使用雪花ID或者高并发写入场景下，这个细节能避免一次凌晨的紧急迁移。

6.3 连接耗尽与并发问题

连接池耗尽这个问题，我有一次在压测环境里被折腾了一下午。现象是服务还能进，但所有请求都卡在数据库查询上，然后时不时抛Timeout acquiring connection。排查下来是两个原因叠加：一个是某个定时任务的循环里，每次迭代都走model查询，但事务/连接没有及时释放，另一个是pool的max配置偏大，数据库侧连接数到达上限。

解决方案分三步走：

• 第一步检查所有事务是否有未完成的await，确保在finally里释放事务，managed transaction就不用担心这个；
• 第二步设置pool的acquire超时，让拿不到连接的请求快速失败而不是无限等待；
• 第三步监控数据库连接数和应用实例数，按实例数反推每个实例的pool.max，总连接数控制在MySQL上限的60%到70%之间。

另外，不要把业务逻辑写在sequelize.define的回调里，也不要在模型方法里自建连接，保持所有操作复用同一个sequelize实例，连接池才能真正起作用。多个sequelize实例并存是连接失控的常见原因，排查的时候先数一下代码里有没有重复new Sequelize。

6.4 不要再无脑sync的反思

第3.3里我说过生产环境不要用sync({ alter: true })。这里补充一个真实案例：有同事为了省事在开发环境自动同步，结果字段类型从INTEGER改成STRING后，MySQL的alter操作把表锁了十几秒，那会儿正好在导数据，直接把任务干崩了。从那以后，我规定任何环境都不允许sync，统一走migration。开发环境想快速建表，可以用migration:generate生成后再db:migrate，流程一样，但每一步变更都可追溯。

如果你是从旧数据库反向生成模型，Sequelize官方有sequelize-auto工具，能根据表结构生成基础模型文件。但它生成的模型往往不够干净，字段类型和索引可能与业务预期不一致，生成后手工检查是必须的。我更建议把这步作为建表第一步的辅助，不要依赖它长期维护模型。

6.5 日常维护的两个小技巧

最后分享两个维护期的技巧。

第一，模型文件多了以后，建议做一个集中的模型索引文件models/index.js，把所有的模型和关联集中导入，导出统一的sequelize实例和模型对象。sequelize-cli init生成的models/index.js会默认同步所有模型文件，但关联关系的定义顺序会影响加载结果，A关联B时B还没有被注册，就会报“关联引用了未定义模型”的错误。我习惯在index.js里显式控制加载顺序，先注册基础模型，再执行关联。

第二，学会用Sequelize的日志定位问题。官方提供logging配置，可以在初始化时传入一个函数，把生成的SQL打到控制台：

new Sequelize(config, { logging: process.env.NODE_ENV === 'development' ? console.log : false });

生产环境记得关掉或存到独立文件，不然每个请求刷两三条SQL，日志量很大。开发环境开着它，基本能看出每一条慢SQL长什么样，再配合EXPLAIN分析，能很快定位索引是否命中。

最后再分享一个小习惯：每次发版前，我都会在生产环境跑一次db:migrate的dry-run，先用sequelize-cli db:migrate --dry感受一下迁移文件会不会有异常，再执行正式迁移。遇到过太多因为迁移顺序写错、字段名和模型不一致导致的发布失败，多花一分钟做这个检查，线上就能少折腾一小时。Sequelize本身提供的能力很丰富，但真正让它好用的，是你对数据和工程的敬畏心。用熟了之后你会发现，ORM不是一个偷懒的工具，而是一个把你从重复劳动里解放出来、让你把精力花在业务设计上的底座。