简介：这份资源围绕 JavaScript 直接访问 MySQL 数据库展开，面向从事 AJAX 开发、希望省去后台服务与复杂 JDBC 调用的前端与全栈开发者。核心是 JSDBC（JavaScript DataBase Connector）组件，通过 OCX 对象在浏览器端建立与 MySQL 的连接，涵盖 connectMySQL、insertMySQL、execDMLMySQL、selectMySQL、deleteMySQL、updateMySQL、callProduceMySQL 等函数用法，并给出 getLastError 错误处理与 closeMySQL 释放连接的完整脚本示例，同时说明其可扩展支持 SQLite、ACCESS 等数据库。资源包共 1 个 doc 文档，约 31KB，内容精炼，适合作为接口速查与调试参考。目前已有 6926 人学习下载，读者可据此快速掌握免部署 Java 环境、免写复杂 JDBC 的数据库直连思路，理解查询结果按行与字段分隔符解析为二维数组的处理方式，并借鉴其错误捕获与连接关闭的写法，用于调试或轻量应用集成。
1. JS 直接访问 MySQL：为什么大多数前端方案一开始就走错了路
浏览器里跑着一段 JS，想直接连上 MySQL 把数据读出来——这个念头几乎每个写过前端的人都动过。页面要展示订单、要渲染报表、要做个内部小工具，数据明明就在那台数据库服务器上，为什么非得绕一层后端接口？于是有人去搜「JS 直接访问数据 Mysql」，搜出来的答案往往两极分化：一边说「用 Node.js 的 mysql2 包就行」，另一边说「浏览器里绝对不行」。这两句话其实都对，只是说的不是同一件事。
关键分歧点在于 JS 的运行位置。跑在浏览器里的 JS，受同源策略和沙箱限制，只能发 HTTP/WebSocket 这类应用层请求，根本拿不到 TCP 层去跟 MySQL 的 3306 端口握手；而跑在 Node.js、Deno 或者 Electron 主进程里的 JS，本质是服务端运行时，有完整的 socket 能力，连 MySQL 完全可行。所以「JS 直接访问 MySQL」真正能落地的形态，是 Node.js 侧的直连，而不是浏览器侧的直连。这篇文章就围绕这个能跑通的形态展开：怎么装驱动、怎么建连接池、参数怎么调、事务怎么写、踩过的坑在哪。适合手里有台 MySQL、想用 JS 快速搭数据层或内部工具的开发者，也适合被「前端直连数据库」这个说法绕晕、想搞清楚边界的人。
2. 选对驱动与运行环境：mysql2 凭什么取代了 mysql
2.1 为什么是 Node.js 侧直连，而不是浏览器
先把边界钉死。浏览器里的 JS 没有裸 TCP 能力，任何声称「浏览器 JS 直连 MySQL」的方案，底下要么是 WebSocket 网关转发，要么是某个中间服务在替你连——那已经不是直连了。真正意义上的 JS 直连，运行环境必须是 Node.js 这类服务端 JS 运行时。这一点想清楚，后面所有选型和参数才有意义。
Node.js 连 MySQL 的驱动，主流就两个：老牌的mysql和现在事实上的标准mysql2。mysql包年久失修，回调风格，对 Promise 支持要靠promise-mysql这类包装；mysql2是它的重写版，原生支持 Promise、支持预处理语句（prepared statement）、性能更好，还兼容大部分mysql的 API。新项目没有理由再用mysql，直接上mysql2。
安装很直接：
npm init -y npm install mysql2mysql2默认走的是回调风格，但提供了mysql2/promise入口，写起来清爽得多。下面这段是最小可运行版本，先确认能连上再说别的：
// db.js —— 最小连接示例，先验证连通性 const mysql = require('mysql2/promise'); async function main() { // 单连接，仅用于验证，生产环境请用连接池 const conn = await mysql.createConnection({ host: '127.0.0.1', port: 3306, user: 'app_user', password: 'your_password', database: 'demo', charset: 'utf8mb4', }); const [rows] = await conn.execute('SELECT 1 + 1 AS result'); console.log(rows); // [ { result: 2 } ] await conn.end(); } main().catch(console.error);逻辑说明：createConnection建立一条物理连接，execute走的是预处理语句通道，返回的[rows, fields]里rows是结果集。参数说明：host建议写127.0.0.1而不是localhost，因为某些环境下localhost会走 Unix socket 而不是 TCP，排查问题时容易误导；charset一定设成utf8mb4，否则 emoji 和部分生僻字会变成问号，这是血泪经验。
2.2 连接池：单连接为什么在生产环境必翻车
单连接能跑通，但一上并发就废。Node.js 是单线程事件循环，一条连接同一时刻只能处理一个查询，第二个请求进来只能排队，QPS 稍微一高就雪崩。正确做法是用连接池，让驱动帮你管理一组连接、按需分配。
// pool.js —— 生产环境用的连接池 const mysql = require('mysql2/promise'); const pool = mysql.createPool({ host: process.env.DB_HOST || '127.0.0.1', port: Number(process.env.DB_PORT) || 3306, user: process.env.DB_USER, password: process.env.DB_PASSWORD, database: process.env.DB_NAME, charset: 'utf8mb4', waitForConnections: true, // 连接耗尽时排队等待，而不是直接报错 connectionLimit: 10, // 池内最大连接数 queueLimit: 0, // 0 表示排队数量不设上限 enableKeepAlive: true, // 保持长连接，减少握手开销 keepAliveInitialDelay: 0, timezone: '+08:00', // 时区，避免时间字段偏移 }); module.exports = pool;参数说明：connectionLimit是最需要拿捏的一个。设太小，高并发下请求排队；设太大，MySQL 侧连接数被打满，反而拖垮数据库。经验值是「单实例 10～20」，再配合 MySQL 的max_connections留出余量。queueLimit: 0表示排队不设上限，配合waitForConnections: true，请求会等而不是立刻失败，但要注意这会让超时表现为「请求卡住」，得在业务层加超时控制。timezone不设的话，DATETIME字段读出来可能差 8 小时，这个坑非常隐蔽。
用池的方式和单连接几乎一样，只是从池里取：
const pool = require('./pool'); async function getUser(id) { const [rows] = await pool.execute( 'SELECT id, name, created_at FROM users WHERE id = ?', [id] ); return rows[0] || null; }注意这里用的是execute而不是query。execute走预处理语句，参数通过占位符?传入，驱动会做转义，天然防 SQL 注入；query是拼接字符串，参数直接内插，写不好就是注入漏洞。除非有特殊需求（比如动态表名，占位符不支持），否则一律用execute。
3. 从建表到查询：把一条完整的数据链路跑通
3.1 建一张带索引的表，别让查询全表扫描
驱动连上了，接下来得有数据。建表时最容易忽略的是索引和字段类型。下面这张表覆盖了常见类型，也顺手把索引建上：
CREATE TABLE orders ( id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT, user_id BIGINT UNSIGNED NOT NULL, amount DECIMAL(10, 2) NOT NULL DEFAULT 0.00, status TINYINT NOT NULL DEFAULT 0, remark VARCHAR(255) DEFAULT NULL, created_at DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP, PRIMARY KEY (id), KEY idx_user_id (user_id), KEY idx_status_created (status, created_at) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;说明：amount用DECIMAL而不是FLOAT，金额计算不能有浮点误差；status用TINYINT省空间；idx_status_created是联合索引，按「状态 + 时间」查列表时能直接命中。DEFAULT 0这种默认值设置，在热词里被反复搜，其实就一句话：字段定义时写DEFAULT 0，插入不传该列就自动填 0，比在应用层兜底更省心。
3.2 增删改查的 JS 写法与参数绑定
有了表，把 CRUD 写全。重点看参数怎么绑、返回值怎么取：
const pool = require('./pool'); // 插入：拿到自增主键 async function createOrder(userId, amount) { const [result] = await pool.execute( 'INSERT INTO orders (user_id, amount, status) VALUES (?, ?, ?)', [userId, amount, 0] ); return result.insertId; // 自增 id } // 查询列表：带分页和排序 async function listOrders(userId, page = 1, size = 20) { const offset = (page - 1) * size; const [rows] = await pool.execute( 'SELECT id, amount, status, created_at FROM orders WHERE user_id = ? ORDER BY created_at DESC LIMIT ? OFFSET ?', [userId, size, offset] ); return rows; } // 更新：注意 affectedRows async function markPaid(orderId) { const [result] = await pool.execute( 'UPDATE orders SET status = ? WHERE id = ? AND status = ?', [1, orderId, 0] ); return result.affectedRows; // 0 表示没更新到（可能已支付） } // 删除 async function removeOrder(orderId) { const [result] = await pool.execute('DELETE FROM orders WHERE id = ?', [orderId]); return result.affectedRows; }逻辑说明：execute返回的数组第一个元素，插入时是OkPacket（含insertId、affectedRows），查询时是结果行数组。参数说明：LIMIT ? OFFSET ?里的占位符，mysql2会按数字处理，但要注意某些旧版本驱动对LIMIT占位符支持有差异，如果报语法错，改成拼接整数（先做parseInt校验）即可。markPaid里加了AND status = 0是乐观锁思路，防止重复支付，affectedRows为 0 就说明状态已经变了，这个模式在订单场景非常实用。
3.3 事务：转账场景下不回滚就是事故
涉及多表写入，必须用事务。mysql2的连接池事务写法有个容易翻车的点：必须从池里取同一条连接，不能每条语句都从池里拿：
const pool = require('./pool'); async function transfer(fromId, toId, amount) { const conn = await pool.getConnection(); // 关键：取同一条连接 try { await conn.beginTransaction(); const [r1] = await conn.execute( 'UPDATE accounts SET balance = balance - ? WHERE id = ? AND balance >= ?', [amount, fromId, amount] ); if (r1.affectedRows === 0) throw new Error('余额不足'); await conn.execute( 'UPDATE accounts SET balance = balance + ? WHERE id = ?', [amount, toId] ); await conn.commit(); } catch (err) { await conn.rollback(); // 出错必须回滚 throw err; } finally { conn.release(); // 关键：归还连接，否则池会被耗尽 } }逻辑说明：getConnection从池里借出一条连接，beginTransaction到commit/rollback之间的所有语句都在这条连接上执行，才属于同一个事务。参数说明：finally里的release绝对不能漏，漏一次就少一条可用连接，跑一段时间池就空了，表现为请求全部卡死——这是最经典的翻车现场。扣款那条 SQL 用balance >= ?做条件更新，把「检查余额」和「扣款」合成原子操作，避免并发下的超扣。
4. 避坑与排查：JS 连 MySQL 最常见的五类翻车
4.1 连接报错 ECONNREFUSED 或 ETIMEDOUT
现象：启动就报connect ECONNREFUSED 127.0.0.1:3306，或者卡很久后ETIMEDOUT。原因：前者通常是 MySQL 没启动、端口不对，或者bind-address只监听了127.0.0.1而你从别的机器连；后者多是防火墙或安全组没放行 3306。解决：先在服务器上mysql -u user -p本地登录确认服务活着，再netstat -tlnp | grep 3306看监听地址，跨机访问要确认bind-address = 0.0.0.0且防火墙放行。
4.2 SSL 连接错误
现象：报ER_SSL_CONNECTION_ERROR或握手失败。原因：MySQL 8.0 默认可能要求或协商 SSL，而客户端配置不匹配。解决：内网可信环境可以显式关闭，连接参数加ssl: false；需要加密则配ssl: { rejectUnauthorized: true }并挂上 CA 证书。别在没搞清楚的情况下盲目rejectUnauthorized: false，那等于放弃了证书校验。
4.3 时间字段差 8 小时
现象：created_at读出来比实际早或晚 8 小时。原因：MySQL 会话时区和 Node.js 进程时区不一致，mysql2默认按本地时区解析DATETIME。解决：连接参数里显式写timezone: '+08:00'，或者统一用 UTC 存储、展示层再转换。这个坑不报错，只是数据悄悄错，最难查。
4.4 连接池耗尽，请求全部卡住
现象：服务跑一阵后所有请求无响应，日志没有明显报错。原因：某处getConnection后没release，或者事务里抛异常没走到finally。解决：所有借连接的地方都用try/finally包住release；给池加监控，定期打印pool.pool._allConnections.length观察连接数是否只增不减。
4.5 中文乱码或 emoji 变问号
现象：写入的中文正常，emoji 或生僻字变成?。原因：库、表、连接三处字符集不一致，某一处还是utf8（MySQL 的utf8只支持 3 字节，不是真正的 UTF-8）。解决：库表建的时候用utf8mb4，连接参数写charset: 'utf8mb4'，三处对齐才行。
5. 进阶技巧：用预处理语句缓存和批量插入把性能再压一档
5.1 预处理语句缓存，别让驱动重复编译
execute每次调用，驱动默认会尝试复用已编译的预处理语句。但有个细节：mysql2的语句缓存是按连接维度的，连接池里每条连接各自缓存。如果你发现高频查询的prepare开销明显，可以确认驱动版本是否支持namedPlaceholders和语句缓存，并保持 SQL 文本完全一致（多一个空格都会当成新语句）。我一般会把高频 SQL 抽成常量，避免在代码里手写导致文本漂移。
5.2 批量插入：一条 INSERT 顶一千条
逐条INSERT在导入数据时慢得让人怀疑人生。正确姿势是拼多值插入：
async function batchInsert(rows) { // rows: [[userId, amount], [userId, amount], ...] if (rows.length === 0) return 0; const placeholders = rows.map(() => '(?, ?)').join(', '); const flat = rows.flat(); const [result] = await pool.execute( `INSERT INTO orders (user_id, amount) VALUES ${placeholders}`, flat ); return result.affectedRows; }逻辑说明：把 N 行拼成一条VALUES (?,?),(?,?),...的 SQL，一次网络往返搞定。参数说明：flat把二维数组拍平成一维，顺序要和占位符一一对应。注意单条 SQL 别太长，超过max_allowed_packet会被截断报错，一般几千行一批比较稳妥，超大批量就分批循环。
5.3 一个验证连接健康度的小习惯
我习惯在服务启动时做一次自检：从池里取连接、执行SELECT 1、再归还，确认整条链路通。上线后如果出现「偶发查询超时」，先看是不是池里存在被 MySQL 侧wait_timeout掐掉的死连接。mysql2的enableKeepAlive能缓解，但更稳的做法是给池配idleTimeout，让空闲连接主动回收。这些参数没有万能值，得结合自己业务的并发曲线去调，我踩过的坑基本都集中在「池参数拍脑袋设」和「忘了 release」这两件事上。把连接池当成有限资源去管理，而不是当成随手可取的全局变量，JS 直连 MySQL 这条路才算真正走稳。希望帮到你。
本文还有配套的精品资源，点击获取
