Knex与mysql2的对比，基于性能、稳定性和ES8+的支持。

Question

有谁有DB库的实践经验-------------------------。knex 与。mysql2?

经过一番上网查询（如在? NPMCCompare)，我还是很想知道，根据实际经验，这两种选择的优点和缺点是什么？

到目前为止，使用 knex 在...上 mysql2，我清楚地看到，是它普遍支持MSSQL、MySQL、PostgreSQL、SQLite3和Oracle，而后者只支持MySQL，但由于目前我只关注MySQL，所以这个 knex'的特点似乎不太相关。

我会考虑的参数。

• 性能&耐负荷性。
• 稳定性（生产准备）。
• 原生的ES8+支持（无回调，无额外的回调）。Util.promisify 包装纸。ESMMJS 支持）。)
• 简洁明了，越不啰嗦越好。

Answer 1

我在我的主要项目上使用knex，我认为你是想拿苹果和橘子比较，因为Knex是一个查询构建器，线下使用（mysql2）作为传输库（在MySql使用的情况下）。

我在Knex中看到的好处是。

1. 防止SQL注入 默认.
2. 让你 建立查询 轻而易举
3. 让你 撰写查询 就像你编写javascript函数一样（在我看来这是一个很大的优势）。

既然#3在我看来是这么大的优势，那就最好演示一下。

想想你有两个端点

1. /users/list - 其中假设返回一个用户列表 ({id, name})
2. /users/:id - 其中，假设返回一个用户与 一样 结构。

你可以这样实现。

async function getAllUsers() {
  return db('users').columns('id', 'name'); //think that this can consist of many joins
}

async function getUserById(userId) {
  return getAllUsers().where('id', userId);
}

看看 getUserById 是重复使用相同的查询（可能真的很复杂），只是 "增加 "了它所需要的限制。

从性能上来说，我不认为这种抽象有很大的代价，（我还没有注意到任何性能问题）。

我不知道你所说的稳定性是指什么，但是Knex有一个非常酷的TS支持，它可以让你的查询强烈地类型化。

interface User {
  id: number;
  name: string;
}

const users = await db<User>('users').columns('id', 'name'); // it will autocomplete the columns names & users will be of type User[] automatically.

通过结合从DB中自动生成这些db类型，使用 @类型化的编码表 (typed-codeschemats) 它让工作& 重构变得更好。

从ES6开始，Knex默认支持Promises & 回调，所以你可以选择任何适合你的方式。

我使用的其他很酷的功能是自动转换大小写，我的db的表& 列名采用蛇形大小写风格，但在我的节点中，我使用骆驼大小写，使用的是 knex-stringcase 插件。

迁移允许你用代码定义如何构建升级你的模式，这可以帮助你从CI中自动更新你的生产模式。

Mysql2是DB上面的一个低级驱动。