在使用 Laravel 进行开发的过程中，打印 SQL 语句是一项非常重要且实用的操作。它有着诸多应用场景，比如当我们使用 Query Builder 构建查询时，只有清楚地知道到底执行了什么 SQL 语句，才能正确且高效地编写 Query Builder。像 “热加载” 和 “懒加载” 场景中，了解 SQL 的执行情况，就能避免一些效率问题的产生。例如在热加载场景下，像 $user = User::where('name', 'Eric')->with('articles')->first(); 这样的语句，Query Builder 可能只使用类似 select * from users where name = 'Eric' limit 1; 以及 select * from articles where user_id in(22); 这样两条 SQL 语句，后续遍历用户文章时就无需再频繁请求数据库了。而与之相对的懒加载，如果不清楚底层 SQL 执行情况，就可能出现明明可以少量次数完成的查询，却执行了多次 SQL 查询的 “N + 1” 问题，导致效率变低。另外，在处理一些较为复杂的业务场景，例如拼接多个 whereRaw 的 SQL 语句时，若程序执行结果与预期不符，通过打印 SQL 语句，观察其实际执行的内容，就能排查出是语句本身构造问题，还是框架执行层面出现了差错。而且在调试自定义的参数绑定查询时，比如根据经纬度手动计算两点之间的近距离这类涉及到自定义 SQL 语句和参数绑定的情况，将 SQL 语句打印出来，有助于确认参数是否正确传入、语句是否符合预期等，方便我们对接口执行的查询语句做具体分析，从而更好地完成开发与调试工作，确保项目顺利进行。总之，掌握 Laravel 中打印 SQL 语句的方法，能为我们开发带来极大的便利呢。

二、Laravel 打印 SQL 语句的方法

（一）开启执行日志法

在 Laravel 中，一种常见的打印 SQL 语句的方法是开启执行日志。具体操作是使用 DB::connection()->enableQueryLog(); 来开启日志记录，然后执行我们的数据库查询操作，比如 $result = DB::table('advert')->whereJsonContains('tag', "1")->get();，最后通过 dd(DB::getQueryLog()); 就能获取到执行的查询语句以及相关的绑定参数和执行时间等信息。这种方法的优点在于它能完整地记录下所有执行过的 SQL 语句，对于我们排查一些复杂业务逻辑中 SQL 的执行情况非常有帮助。例如在一个涉及多个关联表查询和条件筛选的功能模块中，如果出现数据不准确的问题，通过开启执行日志，我们可以清晰地看到每一步查询的具体情况，从而快速定位是哪一个查询出现了偏差。然而，它也有一定的局限性，开启执行日志会在一定程度上影响程序的性能，尤其是在生产环境中，如果大量使用这种方式来打印 SQL 语句，可能会导致系统响应变慢。而且日志信息是存放在内存中的，如果查询语句较多或者数据量较大，可能会占用较多的内存资源。所以这种方法比较适合在开发环境或者测试环境中，对一些关键的业务逻辑进行 SQL 语句的排查和调试。

（二）toSql () 方法

另一种打印 SQL 语句的方法是使用 toSql() 方法。比如对于 $query = DB::table('users')->where('id', 10);，我们可以通过 $query->toSql(); 来获取对应的 SQL 语句。这种方法的优势在于它的使用非常简便，能够快速地获取到我们构建的查询语句的大致样子。不过它也存在一些不足，toSql() 方法获取到的 SQL 语句中参数是用 ? 占位符表示的，并没有显示出实际的参数值。如果我们想要获取完整的带有实际参数值的 SQL 语句，还需要进一步处理，例如 $sql = str_replace_array('?', $query->getBindings(), $query->toSql()); 这样的操作来替换占位符，相对来说比较麻烦。而且这种方法只能获取到当前构建的这一条 SQL 语句，如果在一个方法或者一个业务流程中存在多条 SQL 语句的执行，使用 toSql() 方法就需要逐个去获取，不如开启执行日志法那样可以一次性获取到所有执行过的 SQL 语句。但在一些简单的场景下，比如我们只是想快速查看一下某一条特定查询语句的基本结构，toSql() 方法还是比较方便快捷的。

（三）推荐方法：在 AppServiceProvider 中处理

这里推荐一种更为实用和稳定的方法，即在 AppServiceProvider 的 boot 方法中进行处理。首先，我们打开 app/Providers/AppServiceProvider.php 文件，在 boot 方法中添加以下代码：通过这种方式，我们可以将所有执行的 SQL 语句以及完整的参数信息记录到指定的日志文件中，比如 storage/logs/2024-12-25_query.log（日期会根据实际执行日期生成）。这样做的好处是，在开发和调试过程中，我们可以随时查看这些日志文件，了解程序在运行过程中到底执行了哪些 SQL 语句，并且能够清晰地看到完整的 SQL 语句内容，包括参数值。而且这种方法对程序性能的影响相对较小，因为它是在一个统一的地方进行日志记录的处理，不会像开启执行日志法那样在每个查询的地方都进行额外的日志记录操作，从而避免了过多的性能开销。同时，将日志记录到文件中也便于我们长期保存和分析，对于后续排查一些线上环境中偶尔出现的数据库相关问题也提供了有力的支持。所以，在实际的 Laravel 项目开发中，这种在 AppServiceProvider 中处理 SQL 语句打印的方法是一个比较好的选择。

三、不同方法的对比与选择

（一）使用便捷性对比

开启执行日志法：使用时需要先通过 DB::connection()->enableQueryLog(); 开启日志记录，执行查询操作后，再用 dd(DB::getQueryLog()); 来获取信息，整体步骤不算复杂，但相对而言，在每个需要查看 SQL 语句的地方都要进行这样的操作，略显繁琐。并且在生产环境大量使用还可能影响性能，所以更适合开发和测试环境，使用场景上有一定限制，便捷性打个中等分吧。toSql () 方法：使用起来非常简便，比如对于构建的查询语句 $query = DB::table('users')->where('id', 10);，只需通过 $query->toSql(); 就能快速获取到 SQL 语句的大致样子，在只想简单查看某一条特定查询语句结构时很方便快捷，便捷性方面表现较好，可以打高分。在 AppServiceProvider 中处理：需要打开 app/Providers/AppServiceProvider.php 文件，在 boot 方法中添加相应代码来处理 SQL 语句的记录和打印，初次配置时步骤稍多一些。不过一旦配置好，后续在开发和调试过程中，无需过多额外操作就能自动记录 SQL 语句到日志文件，从长期使用和整体项目角度来看，还是比较方便的，便捷性也能给到中等偏上的分数。

（二）获取信息完整性对比

开启执行日志法：它的优势十分明显，能够完整地记录下所有执行过的 SQL 语句，还能包含相关的绑定参数和执行时间等详细信息，这对于排查复杂业务逻辑中 SQL 的执行情况帮助极大，信息完整性方面可以打高分。toSql () 方法：其获取到的 SQL 语句中参数是用 ? 占位符表示的，并不会直接显示出实际的参数值，如果要获取完整的带有实际参数值的 SQL 语句，还需要进行如 $sql = str_replace_array('?', $query->getBindings(), $query->toSql()); 这样额外的处理操作，所以在信息完整性上有所欠缺，只能打低分。在 AppServiceProvider 中处理：通过这种方式可以将所有执行的 SQL 语句以及完整的参数信息记录到指定的日志文件中，我们能随时查看日志文件了解完整的 SQL 语句内容，包括参数值，在信息完整性方面表现优秀，同样可以打高分。

（三）性能影响对比

开启执行日志法：开启执行日志会在一定程度上影响程序的性能，尤其是在生产环境中，如果大量使用这种方式来打印 SQL 语句，可能会导致系统响应变慢。而且日志信息是存放在内存中的，当查询语句较多或者数据量较大时，还可能占用较多的内存资源，性能影响方面表现较差，只能打低分。toSql () 方法：它只是获取当前构建的这一条 SQL 语句，相对来说对性能的影响较小，不过如果在一个业务流程中有多条 SQL 语句需要查看，逐个获取的过程可能也会有一定的性能损耗，但总体在这三种方法里对性能影响算是比较小的，可打中等分。在 AppServiceProvider 中处理：因为是在一个统一的地方进行日志记录的处理，不会像开启执行日志法那样在每个查询的地方都进行额外的日志记录操作，从而避免了过多的性能开销，对程序性能的影响相对较小，在性能影响这块能打高分。

（四）选择建议

综合以上对比，如果您只是想快速查看某一条查询语句的大致结构，方便简单验证，那么 toSql() 方法是不错的选择，它操作简便，能迅速满足需求。要是处于开发环境或者测试环境，需要排查复杂业务逻辑中 SQL 的具体执行情况，对信息完整性要求很高，并且不太在意一定程度的性能影响以及内存占用问题时，开启执行日志法可以很好地帮助您定位问题，清晰呈现每一步查询情况。而对于实际的 Laravel 项目开发，特别是需要长期记录和查看 SQL 语句，兼顾信息完整性、性能以及方便后续排查线上环境中偶尔出现的数据库相关问题，建议采用在 AppServiceProvider 中处理的方法，虽然配置时稍麻烦一点，但从整个项目周期来看，是最为实用和稳定的选择哦。

四、实际应用案例展示

以下我们通过一个具体的复杂查询案例，来分别使用上述三种方法进行 SQL 语句打印，展示在实际开发中如何运用这些方法进行调试和优化。假设我们正在开发一个电商项目，现在有一个需求是查询出满足特定条件的商品列表以及对应的商家信息，同时还要根据商品的销量进行降序排序，并且只获取前 10 条记录。

（一）使用开启执行日志法

首先，我们使用开启执行日志法来查看执行的 SQL 语句。在相关的控制器方法或者业务逻辑代码处，添加以下代码：通过这样的操作，我们可以获取到类似如下的执行日志信息：从这个结果中，我们可以清晰地看到实际执行的 SQL 语句结构以及参数绑定情况。比如这里能明确看到 where 条件中商品状态的参数值是 1，同时知道是按照 products.sales 字段进行降序排序并且限制了获取 10 条记录。在排查数据是否正确显示、关联查询是否符合预期等问题时，这样完整的日志信息就很有用了。例如，如果发现获取到的商品列表中包含了状态不为 1 的商品，那就可以顺着这条 SQL 语句去检查是条件判断逻辑有误，还是数据在存入时状态值就出现了差错等情况。不过要注意，在生产环境中如果大量使用这种方式，尤其是面对频繁的查询操作时，可能会因为内存占用以及对性能的影响，导致系统响应变慢等问题哦，所以它更适合在开发环境或者测试环境中帮助我们排查问题呢。

（二）使用 toSql () 方法

接下来，我们用 toSql() 方法来尝试获取 SQL 语句。代码可以这样写：运行后，得到的结果大概是这样：可以看到，使用 toSql() 方法能快速获取到查询语句的基本结构，非常简便直观。但正如前面所说，它存在参数显示不完整的问题，这里的参数都是用 ? 占位符表示的。如果我们想要确切知道参数值，还需要进一步处理，像下面这样：经过替换操作后，才能完整显示出带有实际参数值的 SQL 语句。在这个案例中，如果只是想快速查看一下构建的这个查询语句的大致样子，不想去开启执行日志等相对麻烦一点的操作时，toSql() 方法就可以满足需求了，能让我们迅速知晓查询的基本逻辑和结构是否正确。

（三）使用在 AppServiceProvider 中处理的方法

最后，我们看看在 AppServiceProvider 中处理的方法如何运用在这个案例中。先打开 app/Providers/AppServiceProvider.php 文件，在 boot 方法中添加之前介绍的代码：然后正常执行查询操作，也就是和前面类似的代码：这时，我们可以到对应的日志文件（例如 storage/logs/2024-12-25_query.log，日期根据实际执行时间而定）中去查看记录的 SQL 语句信息，可能会看到类似这样的内容：这种方式不仅能完整地记录下带有实际参数值的 SQL 语句，而且对程序性能的影响相对较小，还便于我们长期保存和后续分析。比如在后续项目上线后，如果偶尔出现和这个查询相关的数据异常问题，我们就可以通过查看这些历史的日志文件，快速定位是不是 SQL 语句执行方面出现了状况，帮助我们排查线上环境中的问题哦。通过这个实际的复杂查询案例，大家可以更直观地体会到这三种打印 SQL 语句方法在实际开发中的应用场景和各自的特点，从而根据具体的开发需求和环境，选择最适合的方法来帮助我们进行调试和优化工作啦。

五、总结与注意事项

通过以上内容，我们详细介绍了 Laravel 中打印 SQL 语句的多种方法，包括开启执行日志法、toSql() 方法以及在 AppServiceProvider 中处理的方法，并对它们的使用便捷性、获取信息完整性和性能影响等方面进行了对比分析，同时展示了在实际复杂查询案例中的应用。在实际使用过程中，大家需要注意以下几点：首先，在生产环境中，应谨慎使用开启执行日志法来打印 SQL 语句，因为它可能会对性能产生较大的影响，导致系统响应变慢等问题。而在开发和测试环境中，这种方法对于排查复杂业务逻辑中的 SQL 执行情况非常有帮助，可以根据实际情况合理运用。其次，使用 toSql() 方法时，要清楚它获取的 SQL 语句中参数是用 ? 占位符表示的，如果需要完整的带有实际参数值的 SQL 语句，还需要进行额外的处理操作，避免在不知情的情况下因为参数问题导致对 SQL 语句的理解和调试出现偏差。对于在 AppServiceProvider 中处理的方法，虽然它是一种较为稳定和实用的方法，但在配置代码时要确保准确无误，以免出现记录的 SQL 语句信息不准确或者无法记录的情况。另外，无论使用哪种方法打印 SQL 语句，都要注意代码的安全性和性能优化。避免在不必要的地方频繁打印 SQL 语句，同时要确保打印的 SQL 语句不会泄露敏感信息，防止潜在的安全风险。总之，掌握 Laravel 打印 SQL 语句的方法，能够帮助我们更好地进行数据库查询的调试和优化，提高项目的开发效率和质量，确保项目的稳定运行。希望大家在实际开发中，根据项目的具体需求和环境，灵活选择合适的方法来打印 SQL 语句，为项目的顺利推进提供有力的支持。