简介
在laravel开发中，我们经常需要与数据库进行交互。虽然直接使用原始sql查询（db::raw() 或 db::select()）在某些复杂场景下显得直接有效，但它牺牲了laravel查询构建器提供的诸多便利，如参数绑定带来的安全性、链式调用带来的可读性以及跨数据库的兼容性。尤其是当查询中包含子查询时，将原始sql转换为查询构建器表达式可能会让一些开发者感到困惑。本教程将以一个典型的嵌套查询为例，详细讲解如何利用laravel的fromsub方法优雅地实现这一转换。
原始SQL查询分析
我们首先来看一个包含子查询的原始SQL查询，它旨在计算特定商店员工的订单总价：
SELECT inventory.EmployeeID,
inventory.created_date AS OrderDate,
SUM(inventory.calculation) AS TotalPrice
FROM (
SELECT i.id AS ItemID,
o.id AS OrderID,
o.EmployeeID,
o.created_date,
(o.Quantity * i.price) AS calculation
FROM `stationary_orders` AS o
LEFT JOIN `stationary_items` AS i ON o.Stationary_ID = i.id
WHERE o.Store IN $storess
ORDER BY o.id DESC
LIMIT $Limit,10
) AS inventory
GROUP BY inventory.EmployeeID;这个查询的核心是一个子查询（FROM (...) AS inventory），它首先从 stationary_orders 和 stationary_items 表中获取订单明细，计算每项的价值（calculation），并对结果进行过滤、排序和分页。然后，外部查询基于这个子查询的结果（inventory）按 EmployeeID 分组，计算每个员工的订单总价。
使用Laravel查询构建器转换嵌套查询
Laravel查询构建器提供了fromSub方法，专门用于处理FROM子句中的子查询。它的基本用法是：->fromSub(function ($query) { ... }, 'alias_name')。
下面是将上述原始SQL转换为Laravel查询构建器表达式的步骤和代码：
1. 构建内部子查询
首先，我们需要将原始SQL中的内部子查询部分转换为Laravel查询构建器表达式。这部分查询负责计算每项的价值并进行初步筛选。
use Illuminate\Support\Facades\DB;
// 假设 $stores 和 $limitOffset 是从外部传入的变量
$stores = [1, 2, 3]; // 示例商店ID数组
$limit = 0; // 示例偏移量
$pageSize = 10; // 示例每页数量
$nestedQuery = DB::table('stationary_orders', 'o') // 使用 'o' 作为 orders 表的别名
->select(
'i.id AS ItemID',
'o.id AS OrderID',
'o.EmployeeID',
'o.created_date',
DB::raw('(o.Quantity * i.price) AS calculation') // 计算字段使用 DB::raw
)
->leftJoin('stationary_items AS i', 'o.Stationary_ID', '=', 'i.id') // 使用 'i' 作为 items 表的别名
->whereIn('o.Store', $stores) // 使用 whereIn 处理 IN 子句
->orderBy('o.id', 'DESC')
->offset($limit) // 对应 LIMIT $Limit
->limit($pageSize); // 对应 ,10代码解释：
- DB::table('stationary_orders', 'o'): 开始查询，并为 stationary_orders 表设置别名 o。
- select(...): 选择所需的列。注意，calculation 是一个计算字段，需要使用 DB::raw() 来直接插入SQL表达式。
- leftJoin('stationary_items AS i', 'o.Stationary_ID', '=', 'i.id'): 执行左连接，并为 stationary_items 表设置别名 i。
- whereIn('o.Store', $stores): 安全地处理 WHERE o.Store IN (...) 子句，防止SQL注入。
- orderBy('o.id', 'DESC'): 设置排序规则。
- offset($limit)->limit($pageSize): 对应原始SQL中的 LIMIT $Limit,10。
2. 将子查询嵌入到主查询中
接下来，我们将上述构建好的 $nestedQuery 作为子查询，通过 fromSub 方法嵌入到主查询的 FROM 子句中。
$result = DB::query() // 可以使用 DB::query() 或 DB::table('') 开始一个新查询
->fromSub($nestedQuery, 'inventory') // 将 $nestedQuery 作为子查询，并命名为 'inventory'
->select(
'inventory.EmployeeID',
'inventory.created_date AS OrderDate',
DB::raw('SUM(inventory.calculation) AS TotalPrice') // 再次使用 DB::raw() 处理聚合函数
)
->groupBy('inventory.EmployeeID')
->get(); // 执行查询并获取结果
// $result 将是一个 Illuminate\Support\Collection 对象，其中包含查询结果代码解释：
- DB::query(): 启动一个新的查询构建器实例。
- fromSub($nestedQuery, 'inventory'): 这是关键一步。它将之前构建的 $nestedQuery 视为一个表，并赋予它别名 inventory，就像原始SQL中的 FROM (...) AS inventory 一样。
- select(...): 选择外部查询所需的列。SUM(inventory.calculation) 同样需要 DB::raw()。
- groupBy('inventory.EmployeeID'): 按 EmployeeID 进行分组。
- get(): 执行查询并返回结果集。
完整示例代码
将上述两部分结合起来，完整的Laravel查询构建器代码如下：
input('stores', [1, 2, 3]); // 示例：从请求中获取商店ID数组
$limit = $request->input('offset', 0); // 示例：从请求中获取偏移量
$pageSize = $request->input('limit', 10); // 示例：从请求中获取每页数量
// 1. 构建内部子查询
$nestedQuery = DB::table('stationary_orders', 'o')
->select(
'i.id AS ItemID',
'o.id AS OrderID',
'o.EmployeeID',
'o.created_date',
DB::raw('(o.Quantity * i.price) AS calculation')
)
->leftJoin('stationary_items AS i', 'o.Stationary_ID', '=', 'i.id')
->whereIn('o.Store', $stores)
->orderBy('o.id', 'DESC')
->offset($limit)
->limit($pageSize);
// 2. 将子查询嵌入到主查询中
$employeeOrderSummary = DB::query()
->fromSub($nestedQuery, 'inventory')
->select(
'inventory.EmployeeID',
'inventory.created_date AS OrderDate',
DB::raw('SUM(inventory.calculation) AS TotalPrice')
)
->groupBy('inventory.EmployeeID')
->get();
return response()->json($employeeOrderSummary);
}
}注意事项与最佳实践
- 别名管理： 在使用 leftJoin 或 fromSub 时，务必为表或子查询指定清晰的别名，并在 select 和 where 子句中正确引用这些别名，以避免列名冲突和歧义。
- DB::raw() 的使用： 对于需要直接插入原始SQL表达式的场景（如计算字段、聚合函数、复杂的条件表达式），DB::raw() 是必不可少的。但应谨慎使用，确保其内容不会引入SQL注入风险。
- 参数绑定： Laravel查询构建器会自动处理 where、whereIn 等方法中的参数绑定，这极大地增强了查询的安全性。避免在 DB::raw() 中直接拼接用户输入。
- 可读性与维护性： 尽管查询构建器可能比原始SQL稍微冗长，但其链式调用和结构化的方式使得代码更易于阅读和维护。
- 性能考量： 转换为查询构建器通常不会对查询性能产生负面影响，因为Laravel最终会将其编译为优化的SQL语句。但复杂的嵌套查询本身可能存在性能瓶颈，应根据实际情况进行索引优化和查询重构。
- 调试： 如果在转换过程中遇到问题，可以使用 ->toSql() 方法查看查询构建器生成的原始SQL语句，或者使用 ->dump() 方法（Laravel 8+）来打印查询及其绑定参数，这对于调试非常有帮助。
总结
通过本教程，我们详细演示了如何利用Laravel查询构建器的 fromSub 方法，将复杂的原始SQL子查询转换为更具Laravel风格的、安全且易于维护的代码。掌握这一技巧，将帮助开发者更有效地利用Laravel的强大功能，构建出高质量的数据库交互逻辑。在处理嵌套查询时，记住分解问题、逐步构建子查询，并最终将其集成到主查询中，将使整个过程变得更加清晰和可控。
