Pour certaines raisons, vous ne pouvez pas utiliser Laravel DebugBar, cet article peut vous aider.
L'optimisation des applications Laravel va bien au-delà de l'élimination du problème N+1. Une utilisation appropriée de Laravel DebugBar peut fournir des solutions raisonnables à des problèmes tels que l'utilisation de la mémoire du modèle et la rapidité des requêtes SQL.
Peut-être que vous n'aimez pas utiliser Laravel DebugBar, ou que vous ne pouvez pas l'utiliser pour certaines raisons (telles que le développement d'applications basées sur une interface), alors Database Listener sera une bonne méthode, il enregistrera votre Requête SQL à enregistrer.
Ceci est également applicable dans l'environnement de production et l'environnement de test. Vous pouvez facilement contrôler s'il est activé via env ou config.
Comment utiliser :
Ajoutez ceci à la méthode de démarrage de votre AppServiceProvider
if (env("SQL_DEBUG_LOG")) { DB::listen(function ($query) { Log::debug("DB: " . $query->sql . "[". implode(",",$query->bindings). "]"); }); }
Si vous l'utilisez dans un environnement de production, je vous suggère de le mettre dans la configuration Mettre les informations de configuration dans env, puis vous pouvez (et devriez) mettre en cache ces informations de configuration
J'ai trouvé un autre problème est que si l'appel sql lui-même échoue, une exception sera levée et il écoutera avant le succès call DB::listen ne se connecte pas et l'exception se produit avant de revenir à l'écouteur.
Tutoriels recommandés : "Tutoriel PHP" "Tutoriel Laravel"
Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!