Laravel Eloquent vs SelectRaw。它如何影响查询性能？答案

【问题标题】：Laravel Eloquent vs SelectRaw. How does it effect on query performance?Laravel Eloquent vs SelectRaw。它如何影响查询性能？
【发布时间】：2017-11-06 14:16:07
【问题描述】：

当我们将 Eloquent 与 SelectRaw 用于以下场景时，Laravel 如何处理查询：

这会更快地获取数据吗：

$data = Records::where('active', 1)->get();

或者这会更快地获取我的数据：

$data = DB::select( DB::raw("SELECT * from records WHERE active ='1'") );

当我们处理大约 5,00,000 条记录的大数据时，使用 SelectRaw 是否会影响查询处理速度？

【问题讨论】：

有什么具体的例子吗？
这个更新的描述好吗？
您可以使用 toSQL() 而不是 get() 来检查实际查询是什么。在这种情况下，它们将是相同的，所以没有区别

标签： php laravel laravel-5 eloquent

【解决方案1】：

使用任何 ORM 总会有一些开销。然而，这几乎总是不成问题的。

例如，虽然编写原始 SQL 可能会略微提高性能，但与最初进行查询的成本相比，它通常相形见绌。与在原始 SQL 中重写 ORM 查询相比，缓存响应可以获得更大的性能提升。

ORM 确实使某些类型的慢速低效查询更有可能发生，但这可以通过使用像 Clockwork 这样的分析器来识别慢速或不必要的查询并重构它们来解决。大多数 ORM 都有处理 the N+1 problem 之类的工具 - 例如，Eloquent 有 with() 方法来急切加载相关表，这通常比显式编写查询来为您执行急切加载要方便得多。

使用 ORM 还为开发人员带来了显着的好处：

通常更容易表达表之间的关系
它有助于避免 PHP 和 SQL 之间的心理上下文切换
它为您完成了大量清理数据的工作
它有助于使您的应用程序在不同数据库之间移植（例如，您可以使用 SQLite 进行测试，但在生产中使用 MySQL）
如果您有无法使用 ORM 表达的逻辑，通常可以轻松地为该部分编写原始 SQL

如果您在 Web 应用程序中有一个缓慢的查询，那么将其重写为原始查询可能是您应该考虑做的最后一件事，之后：

重构查询以提高效率/删除不必要的查询
确保在您的数据库中设置了适当的索引
缓存响应

将所有查询编写为原始查询是一种微优化 - 付出很多工作却没有多少回报，而且考虑到开发人员时间比服务器时间昂贵得多，因此几乎不值得费心。即使您有一个非常可怕的查询或一组具有巨大开销的查询，也有更好的方法来处理它——在这种情况下，我倾向于在迁移中创建一个存储过程并调用它而不是直接查询。

【讨论】：