在 Strongloop Loopback 中执行本机 SQL 时的性能损失

Question

与使用连接模型相比，使用 {dataSource.connector.execute(sql, params, cb) 或 dataSource.connector.query(sql, params, cb)} 执行本机 SQL 查询有什么缺点吗？

我最近使用 Native SQL 和连接模型的示例数据测试了相同的场景。当我使用 Native SQL 时，我注意到当我增加负载时 MYSQL 连接会丢失。但同样的操作性能与 Loopback 的连接模型和过滤器相比，与 Native SQL 连接器相比，它可以承受几乎 4 倍的负载。

Loopback 也不推荐使用 Native SQL Connector：

此功能未经过全面测试，未正式发布 支持：API 可能会在未来的版本中更改。一般来说，它是 通过连接模型执行数据库操作总是更好。 直接执行 SQL 可能会导致意外的结果、损坏的数据、 和其他问题。 - Loopback

所以我的确切问题是，有没有人注意到使用本机 SQL 而不是 Loopback 的连接模型的任何缺点或性能损失？

Answer 1

简单地说，运行原始查询（本机 sql）可能比使用 ORM（模型）更快，因为它们执行验证、从您提供的参数和过滤器构建查询等，而运行原始查询只需将查询发送到连接的 sql网络上的服务器，而无需经过所有这些额外的层，但这些差异可能几乎看不到。现在的行业标准是您应该使用 ORM（模型）来访问您的数据，因为它们可以保护您免受许多威胁，例如 sql 注入和简单的人为错误，因为它基于模式执行全面的验证。所以简单地说 ORM 比原始查询更安全。但它是一个选择问题，你想做什么。老实说，我处于中间的某个位置，我尽可能使用 ORM 提供的模型，但我发现在某些情况下，运行 Raw 查询带来了更多的简单性，例如当您必须对超过 2 个表执行联接以及使用查询操作数据时使用 ORM。最后一点只是我做事的方式，在许多人看来可能是错误的。我建议使用 ORM，即。在您的情况下，尽可能使用强循环连接器。