Node.js与MySQL的搭配，核心就是mysql2驱动连接数据库、mysqldump做备份、rsync做跨机迁移这三板斧，90%的服务器数据管理需求都落在这一条主线上。
先理清：Node.js到底怎么和MySQL打交道
node.js连接mysql数据库的正确姿势
老项目还在用mysql包？现在官方推荐的是mysql2，同等API下多了预编译语句、Promise支持和更好的字符集处理，连接之前，先确认服务器上的MySQL版本，8.0以上直接用caching_sha2_password认证，mysql包对这块支持不友好,容易报错。
安装命令就一条：
npm install mysql2
连接池才是生产环境的标配
单连接跑开发环境没问题，但服务器上并发一上来，频繁创建连接就是灾难。连接池能复用已建立的连接，把建立连接的开销摊薄,代码里这么写：
const mysql = require('mysql2/promise');
const pool = mysql.createPool({
host: 'localhost',
user: 'data_user',
password: '你的密码',
database: 'app_db',
waitForConnections: true,
connectionLimit: 10,
queueLimit: 0
});
const [rows] = await pool.query('SELECT FROM users WHERE id = ?', [userId]);
注意这里用的是占位符传参，不是拼字符串，拼SQL字符串哪天被注入攻击了,后悔都来不及。
查完数据要做的三件事
- 用
console.log先看一眼结构，确认字段名没拼错 - 关掉不再用的连接，
pool.end()或connection.release() - 把高频查询的结果做缓存，Redis或内存都行，MySQL扛不住每秒上千次重复查询
服务器数据库怎么备份：别等数据丢了才想起来补课
很多团队备份策略是“想到了才备份”，这等于没备份，服务器上MySQL的数据目录通常在/var/lib/mysql，但光拷贝这个目录是错的数据库引擎自己的缓存和日志文件会让你备份出来的数据处于不一致状态。
逻辑备份与物理备份选哪个
| 备份方式 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|
| mysqldump逻辑备份 | 生成SQL文本，跨版本迁移方便 | 数据量大时速度慢、恢复耗时 | 中小库、日常备份 |
| 物理备份（xtrabackup） | 备份快，恢复也快 | 必须匹配MySQL版本，文件体积大 | 大库（100GB以上） |
中小型项目，mysqldump完全够用，大库用xtrabackup做物理备份,两者不冲突。
备份要定闹钟，不要靠“记得”
在Linux服务器上写个定时任务,crontab配置如下：
0 3 /usr/bin/mysqldump -u backup_user -p'密码' --single-transaction --routines --triggers app_db | gzip > /backup/mysql/app_db_$(date +\%F).sql.gz
--single-transaction：不锁表，InnoDB引擎在线备份的关键参数--routines --triggers：连存储过程和触发器一起备份，不然恢复时容易缺少对象- 管道直接压缩，节省磁盘空间
备份验证比备份动作本身还重要
统计下来，相当一部分备份文件在真正需要恢复时是坏的，每月挑一次备份，从备份文件恢复到临时库，跑几条关键SQL确认数据完整,这步骤不能省。
常用mysql数据库备份命令场景拆解
只备份某张表而不是全库
mysqldump -u root -p app_db users > /backup/users.sql
这种场景多在数据归档时出现，比如把三个月前的订单表导出来,主库只保留近期数据。
把备份恢复到另一台服务器
mysql -u root -p target_db < /backup/app_db_20260101.sql
执行之前确认target_db已创建且字符集与源库一致，utf8mb4是现在的主流选择,utf8存不了emoji。
场景三批量导入大量SQL文件
for f in /backup/split_.sql; do mysql -u root -p app_db < $f done
当备份文件上GB级别时，拆分成小文件分批导入，比一个超大文件执行起来稳得多,哪里报错也能快速定位。
跨服务器迁移MySQL数据：从一台机器搬到另一台
换服务器Linux系统也好、机房迁移也好，
数据搬家的核心是别丢数据。
全量迁移用管道直传最省事
mysqldump -u root -p source_db | ssh user@new-server "mysql -u root -p target_db"
中间不走磁盘，备份完直接在新服务器上落地,少一份中间文件就少一分泄密风险。
不停机迁移怎么操作
先做一次全量备份，然后开启binlog记录增量变更，用mysqlbinlog把差异部分追到新服务器上,步骤：
- 源库开启
log_bin=ON，确认binlog格式为ROW - 记录当前binlog文件和位置：
SHOW MASTER STATUS; - 全量备份恢复到新库
- 用
mysqlbinlog --start-position=xxx回放增量日志
行业共识认为，这套流程是零停机迁移MariaDB/MySQL的标准解法，配合keepalived做VIP漂移,业务侧完全无感知。
迁移后必查的三张表和两个权限
- 检查
mysql.user表，确认新库没有多余的远程root授权 - 检查
information_schema.tables，确认所有表都迁移到位 - 检查
performance_schema，确认统计信息已刷新，旧库的慢查询问题不会带过来 - 应用账号的host设置要改成新服务器的IP
- 存储过程、函数、事件要单独核对一遍，mysqldump有时会因为权限问题漏掉
服务器上常见的MySQL数据问题：慢查询、锁表、连接数打满
慢查询怎么定位
SET GLOBAL slow_query_log = ON; SET GLOBAL long_query_time = 2;
执行完这两条命令，跑两秒以上的SQL都会记录到日志文件里。多数情况下慢SQL是索引没走对，用EXPLAIN看一下执行计划，type字段是ALL就说明全表扫描了,赶紧加索引。
连接数爆了怎么办
先看当前连接：
SHOW PROCESSLIST;
Too many connections报错的典型解决办法：
- 把
max_connections调大，但治标不治本 - 关掉Sleep状态的空闲连接，这些连接只占着位置不用资源
- 核心是检查应用侧有没有连接泄漏，连接池的connection排满又不释放，数据库这边必然爆
锁表导致业务卡死
遇到Lock wait timeout exceeded别急着杀进程,先执行：
SELECT FROM information_schema.innodb_trx\G
找到最老事务的trx_mysql_thread_id，用KILL命令安全终止，长期方案是：事务里不要有外部HTTP调用，有网络等待的事移到事务外做,这是锁表的最常见导火索。
MySQL安全加固别跳过
- 用最小权限账号连库，
SELECT和INSERT分开授权，别一个root走天下 - 远程连接限制IP，云服务器安全组加上白名单
- 加固端口，默认3306改成自定义端口，减少端口扫描的攻击面
Q&A：服务器js mysql数据库数据常见问题排查
Node.js连接MySQL时为什么报错“Client does not support authentication protocol”
MySQL 8.0默认认证插件是caching_sha2_password，旧版mysql包不支持这个协议，解决办法：升级到mysql2驱动，或者在MySQL侧把这个用户改成mysql_native_password插件（后者是权宜之计，新版数据库已在逐步废弃）。
mysqldump备份出来的文件特别大，怎么压缩和分片
管道接gzip压缩，压缩率按表结构不同通常在5到10倍之间，再大的文件可以配合split命令分片：
mysqldump -u root -p app_db | split -b 500M - /backup/app_db.chunk_
分片后上传对象存储（如简米云OSS、酷番云COS），配合生命周期规则自动归档冷存储，成本能再降一截，恢复时用cat /backup/app_db.chunk_ | mysql -u root -p app_db顺序导入。
备份恢复后自增ID和原表不一致，是什么原因
mysqldump默认会把表结构中的AUTO_INCREMENT值一并导出，如果导入时用的账号权限不足或者目标表已存在冲突数据，这个值会偏差，恢复前检查备份SQL里有没有AUTO_INCREMENT=xxx这行，恢复后用ALTER TABLE your_table AUTO_INCREMENT = 1;根据实际max(id)+1重置，常用mysql数据库备份命令场景里，这种情况在导入旧备份时占比不小，定期用mysqlcheck校验表状态能提前发现类似隐患。