Laravel复杂查询优化指南

最近发现不少小伙伴都对文章很感兴趣，所以今天继续给大家介绍文章相关的知识，本文《Laravel 查询优化：复杂AND/OR条件实现指南》主要内容涉及到等等知识点，希望能帮到你！当然如果阅读本文时存在不同想法，可以在评论中表达，但是请勿使用过激的措辞~

1. 理解 Laravel 查询中的隐式 AND 行为

在 Laravel 的查询构建器中，当我们使用数组形式的 where 条件时，所有条件默认会通过 AND 逻辑进行连接。例如，以下代码片段：

$entrys = t_e_elem::where([
    ['t_e_elem.fuse', '=', 1],
    ['t_entry.etitle', 'ilike', $title],
    ['t_entry.edesc', 'ilike', $title]
]);

这段代码在底层会被翻译成如下 SQL 语句：

SELECT * FROM `t_e_elems`
WHERE (`t_e_elem`.`fuse` = ? AND `t_entry`.`etitle` ILIKE ? AND `t_entry`.`edesc` ILIKE ?)

可以看到，t_entry.etitle 和 t_entry.edesc 之间的关系是 AND。然而，在许多搜索场景中，我们可能希望实现“标题包含某个词 或者 描述包含某个词”的逻辑，即 OR 关系。如果按照上述写法，t_entry.edesc 的条件将作为独立的 AND 条件，导致查询结果不符合预期，只返回同时满足所有条件的记录。

我们期望的 SQL 结构通常是这样的：

SELECT * FROM `table_name`
WHERE `some_column` = ? AND (`t_entry`.`etitle` ILIKE ? OR `t_entry`.`edesc` ILIKE ?)

这里的关键在于 AND 后面紧跟着一个用括号括起来的 OR 条件组。

2. 解决方案：使用闭包构建 OR 条件组

Laravel 查询构建器提供了一种优雅的方式来处理这种复杂的 AND/OR 混合逻辑，那就是使用闭包（Closure）作为 where 方法的参数。通过在闭包内部定义条件，我们可以创建一个独立的条件组，该组内部的条件可以自由地使用 AND 或 OR 连接，并且整个组会作为一个单元与外部条件通过 AND 连接。

核心思想是：

$query->where(function ($subQuery) use ($variable) {
    $subQuery->where('column1', 'operator', $variable)
             ->orWhere('column2', 'operator', $variable);
});

让我们将这个方法应用到上述问题中。如果我们需要 t_entry.etitle 或 t_entry.edesc 满足 ilike $title，同时 t_e_elem.fuse 必须为 1，那么可以这样构建查询：

$entrys = t_e_elem::where('t_e_elem.fuse', '=', 1)
    ->where(function ($query) use ($title) {
        $query->where('t_entry.etitle', 'ilike', $title)
              ->orWhere('t_entry.edesc', 'ilike', $title);
    });

这段代码会生成以下 SQL 语句：

SELECT * FROM `t_e_elems`
WHERE `t_e_elem`.`fuse` = ? AND (`t_entry`.`etitle` ILIKE ? OR `t_entry`.`edesc` ILIKE ?)

这正是我们所期望的，ilike 条件被正确地组合成了 OR 逻辑，并且整个 OR 组又通过 AND 与 fuse 条件连接。

3. 完整代码示例与应用

现在，我们将这个解决方案整合到原始的 getTotalEntryByTitle 函数中，以确保在所有需要 ilike 搜索的地方都正确应用 OR 逻辑。

<?php

namespace App\Http\Controllers;

use Illuminate\Http\Request;
use App\Models\t_data_enum;
use App\Models\t_e_elem;
use App\Models\t_entry_form;

class EntryController extends Controller
{
    public function getTotalEntryByTitle($title)
    {
        $total = [];

        // 获取所有省份数据
        $provinces = t_data_enum::where('ekey', 'province')->orderBy('etext', 'ASC')->get();

        foreach ($provinces as $province) {
            // 初始化查询构建器
            $entryQuery = t_e_elem::selectRaw('t_entry.*, t_e_elem.*')
                ->join('t_entry', 't_e_elem.eid', '=', 't_entry.eid')
                ->join('t_e_value', 't_e_elem.fid', '=', 't_e_value.elid')
                ->join('t_entry_form', 't_e_value.fid', '=', 't_entry_form.fid')
                // 1. 应用 fuse 条件
                ->where('t_e_elem.fuse', '=', 1)
                // 2. 应用 AND (etitle ILIKE OR edesc ILIKE) 条件
                ->where(function ($query) use ($title) {
                    $query->where('t_entry.etitle', 'ilike', $title)
                          ->orWhere('t_entry.edesc', 'ilike', $title);
                });

            // 3. 应用 entry 状态条件
            $entryQuery->where('t_entry.estatus', '1');

            // 4. 获取省份字段 ID
            $formIdP = t_entry_form::where([['etype', 1], ['fname', 'field_province']])->first()->fid;

            // 5. 应用省份筛选条件
            $entryQuery->where([
                ['t_e_value.fid', '=', $formIdP],
                ['t_e_value.vvalue', '=', $province->eval]
                // 注意：这里的 t_e_elem.fuse = 1 已经包含在上面的查询中，无需重复
            ]);

            // 6. 应用 DISTINCT 和再次确认搜索条件（如果需要）
            // 这里的 distinct 应该在 select 之后，get 之前
            // 同时，如果之前的 where 已经包含了搜索逻辑，这里可以简化或移除
            // 但为了与原问题保持一致，我们再次应用 OR 逻辑
            $finalEntrys = $entryQuery->distinct("t_entry.eid")
                ->where(function ($query) use ($title) { // 再次确保搜索条件
                    $query->where('t_entry.etitle', 'ilike', $title)
                          ->orWhere('t_entry.edesc', 'ilike', $title);
                })
                ->get();

            array_push($total, [
                'name' => $province->etext,
                'count' => count($finalEntrys)
            ]);
        }

        return $total;
    }
}

在上述代码中，主要的修改点位于 entryQuery 的构建部分和 distinct 之后的 where 条件。我们移除了数组形式的 ilike 条件，并将其替换为闭包形式的 where 子句，以正确地实现 OR 逻辑。

4. 注意事项与最佳实践

• 理解 where 数组与闭包的区别：
  • where(['col1' => 'val1', 'col2' => 'val2']) 或 where([['col1', '=', 'val1'], ['col2', '=', 'val2']])：所有条件默认以 AND 连接。
  • where(function($query) { ... })：用于创建独立的条件组，组内可自由使用 where、orWhere、whereNull 等方法，并且整个组会作为父查询的一个 AND 条件。
• 调试查询： 在开发过程中，强烈建议使用 toSql() 方法来查看 Laravel 生成的实际 SQL 语句，以验证查询逻辑是否符合预期。例如：

  $query = t_e_elem::where('t_e_elem.fuse', '=', 1)
      ->where(function ($q) use ($title) {
          $q->where('t_entry.etitle', 'ilike', $title)
            ->orWhere('t_entry.edesc', 'ilike', $title);
      });
  dd($query->toSql(), $query->getBindings());

  这将输出生成的 SQL 字符串和绑定的参数，帮助你快速定位问题。

• 代码可读性： 尽管闭包增加了查询的灵活性，但过于复杂的嵌套闭包可能会降低代码可读性。在设计复杂查询时，应力求清晰和模块化。
• 性能考量： 复杂的 OR 条件，特别是跨多个列的 OR 条件，可能会影响数据库索引的使用效率。在处理大量数据时，应关注查询性能，并考虑通过优化索引、重构查询或使用全文搜索等方式来提高效率。
• 重复条件： 在原始代码中，ilike 条件在查询链中出现了多次。一旦在查询构建器的早期阶段应用了正确的 AND (OR) 逻辑，后续的 where 条件通常不需要重复相同的搜索逻辑，除非有特殊需求。在上述修正后的代码中，为了与原问题意图保持一致，我们保留了 distinct 后的重复 where，但在实际应用中可以根据具体业务逻辑进行精简。

好了，本文到此结束，带大家了解了《Laravel复杂查询优化指南》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多文章知识！