Comment déboguer les requêtes de base de données PDO?


141

Avant de passer à PDO, j'ai créé des requêtes SQL en PHP en concaténant des chaînes. Si j'ai une erreur de syntaxe de base de données, je pourrais simplement faire écho à la chaîne de requête SQL finale, l'essayer moi-même dans la base de données et la modifier jusqu'à ce que je corrige l'erreur, puis la remettre dans le code.

Les instructions PDO préparées sont plus rapides, meilleures et plus sûres, mais une chose me dérange: je ne vois jamais la requête finale telle qu'elle est envoyée à la base de données. Lorsque j'obtiens des erreurs sur la syntaxe dans mon journal Apache ou mon fichier journal personnalisé (je consigne les erreurs dans un catchbloc), je ne peux pas voir la requête qui les a provoquées.

Existe-t-il un moyen de capturer la requête SQL complète envoyée par PDO dans la base de données et de la consigner dans un fichier?


4
Il est connecté dans un fichier: /var/log/mysql/*. Les paramètres liés à PDO ne peuvent pas provoquer d'erreurs de syntaxe, il vous suffit donc de la requête SQL préparée.
Xeoncross

1
voir le code dans stackoverflow.com/questions/210564/… (pas dans la réponse acceptée). Non pas qu'il y ait eu quelques mises à jour publiées.
Mawg dit de réintégrer Monica le

1
Une ligne simple via Composer: github.com/panique/pdo-debug
Sliq

2
La réponse de Xeoncross m'a aidé. Voici un article expliquant comment activer cette fonctionnalité. Il est désactivé par défaut sur de nombreuses installations de serveurs. pontikis.net/blog/how-and-when-to-enable-mysql-logs
mrbinky3000

2
Essayez avecvar_dump($pdo_instance->debugDumpParams())
Daniel Petrovaliev

Réponses:


100

Tu dis ça :

Je ne vois jamais la requête finale telle qu'elle est envoyée à la base de données

Eh bien, en fait, lorsque vous utilisez des instructions préparées, il n'y a pas de " requête finale " :

  • Tout d'abord, une déclaration est envoyée à la base de données et y est préparée
    • La base de données analyse la requête et en construit une représentation interne
  • Et, lorsque vous liez des variables et exécutez l'instruction, seules les variables sont envoyées à la base de données
    • Et la base de données "injecte" les valeurs dans sa représentation interne de l'instruction


Donc, pour répondre à votre question :

Existe-t-il un moyen de capturer la requête SQL complète envoyée par PDO dans la base de données et de la consigner dans un fichier?

Non: comme il n'y a aucune " requête SQL complète " nulle part, il n'y a aucun moyen de la capturer.


La meilleure chose que vous puissiez faire, à des fins de débogage, est de «reconstruire» une «vraie» requête SQL, en injectant les valeurs dans la chaîne SQL de l'instruction.

Ce que je fais habituellement, dans ce genre de situations, c'est:

  • echo le code SQL qui correspond à l'instruction, avec des espaces réservés
  • et utilisez var_dump (ou un équivalent) juste après, pour afficher les valeurs des paramètres
  • C'est généralement suffisant pour voir une erreur possible, même si vous n'avez aucune requête "réelle" que vous pouvez exécuter.

Ce n'est pas génial, quand il s'agit de débogage - mais c'est le prix des instructions préparées et les avantages qu'elles apportent.


1
Excellente explication - merci. Apparemment, je n'avais que des idées floues sur la façon dont cela fonctionne. Je suppose que lorsque la déclaration est préparée, l'objet résultant contient un hachage ou un identifiant numérique qui peut être renvoyé à la base de données avec les paramètres à brancher.
Nathan Long

Vous êtes les bienvenus :-) ;;; Je ne sais pas comment cela est implémenté dans les détails, mais je suppose que c'est quelque chose comme ça - le résultat est exactement comme ça, de toute façon ;;; c'est l'une des bonnes choses avec les instructions préparées: si vous devez exécuter la même requête plusieurs fois, elle ne sera envoyée à la base de données et préparée qu'une seule fois: pour chaque exécution, seules les données seront envoyées.
Pascal MARTIN

1
Mise à jour: Aaron Patterson a mentionné à Railsconf 2011 qu'il avait ajouté plus d'instructions préparées à Rails, mais que l'avantage est beaucoup plus lourd dans PostgreSQL que dans MySQL. Il a dit que c'était parce que MySQL ne crée pas réellement le plan de requête tant que vous n'exécutez pas la requête préparée.
Nathan Long le

85

Recherche dans le journal de la base de données

Bien que Pascal MARTIN ait raison de dire que PDO n'envoie pas la requête complète à la base de données en une seule fois, la suggestion de ryeguy d'utiliser la fonction de journalisation de la base de données m'a en fait permis de voir la requête complète assemblée et exécutée par la base de données.

Voici comment: (Ces instructions concernent MySQL sur une machine Windows - votre kilométrage peut varier)

  • Dans my.ini, sous la [mysqld]section, ajoutez une logcommande, commelog="C:\Program Files\MySQL\MySQL Server 5.1\data\mysql.log"
  • Redémarrez MySQL.
  • Il commencera à enregistrer chaque requête dans ce fichier.

Ce fichier augmentera rapidement, alors assurez-vous de le supprimer et de désactiver la journalisation lorsque vous avez terminé les tests.


1
Juste une note - j'ai dû échapper aux barres obliques dans my.ini. Donc, mon entrée ressemblait à quelque chose comme log = "C: \\ temp \\ MySQL \\ mysql.log".
Jim

4
Cela peut fonctionner selon le réglage de PDO::ATTR_EMULATE_PREPARES. Voir cette réponse pour plus d'informations: stackoverflow.com/questions/10658865/#answer-10658929
webbiedave

23
Je déteste l'AOP à cause de ça.
Salman le

1
@webbiedave - oh, wow! Votre réponse liée implique que ma réponse ne fonctionne que lorsque PDO ne fonctionne pas de manière optimale, mais envoie plutôt la requête entière pour une compatibilité descendante avec l'ancienne version de MySQL ou un ancien pilote. Intéressant.
Nathan Long

13
Dans MySQL 5.5+, vous avez besoin general_logau lieu de log. Voir dev.mysql.com/doc/refman/5.5/en/query-log.html
Adrian Macneil

18

Bien sûr, vous pouvez déboguer en utilisant ce mode. {{ PDO::ATTR_ERRMODE }} Ajoutez simplement une nouvelle ligne avant votre requête, puis vous afficherez les lignes de débogage.

$db->setAttribute( PDO::ATTR_ERRMODE, PDO::ERRMODE_WARNING );
$db->query('SELECT *******');  

Vous n'appeleriez pas ->querylorsque vous utilisez des instructions préparées?
EoghanM

Merci, cela m'a beaucoup aidé! :)
déverrouiller le

17

Ce que vous voulez probablement faire est d'utiliser debugDumpParams () sur le descripteur de l'instruction. Vous pouvez l'exécuter à tout moment après la liaison des valeurs à la requête préparée (pas besoin de execute()l'instruction).

Il ne construit pas l'instruction préparée pour vous, mais il affichera vos paramètres.


2
Le seul problème est qu'il génère le débogage au lieu de le stocker en interne sans le «faire écho». Je ne peux pas l'enregistrer de cette façon.
Ricardo Martins

3
Vous pouvez utiliser la mise en mémoire tampon de sortie (ob_start () ...) pour stocker la sortie et la consigner.
Cranio

bugs.php.net/bug.php?id=52384 corrigé en 7.1 vous pouvez voir les valeurs :) un peu tard mais c'est php
Sander Visser

12

Un ancien message mais peut-être que quelqu'un trouvera cela utile;

function pdo_sql_debug($sql,$placeholders){
    foreach($placeholders as $k => $v){
        $sql = preg_replace('/:'.$k.'/',"'".$v."'",$sql);
    }
    return $sql;
}

1
Pour une fonction similaire qui peut également gérer des paramètres numériques, voir ma réponse (merci à un commentateur sur php.net).
Matt Browne

9

Voici une fonction pour voir quel sera le SQL effectif, adapté d'un commentaire de "Mark" sur php.net :

function sql_debug($sql_string, array $params = null) {
    if (!empty($params)) {
        $indexed = $params == array_values($params);
        foreach($params as $k=>$v) {
            if (is_object($v)) {
                if ($v instanceof \DateTime) $v = $v->format('Y-m-d H:i:s');
                else continue;
            }
            elseif (is_string($v)) $v="'$v'";
            elseif ($v === null) $v='NULL';
            elseif (is_array($v)) $v = implode(',', $v);

            if ($indexed) {
                $sql_string = preg_replace('/\?/', $v, $sql_string, 1);
            }
            else {
                if ($k[0] != ':') $k = ':'.$k; //add leading colon if it was left out
                $sql_string = str_replace($k,$v,$sql_string);
            }
        }
    }
    return $sql_string;
}

Pourquoi "Mark" utilise-t-il deux points avant $ k dans str_replace(":$k" ....? Les index associatifs l'ont déjà dans le tableau $ params.
Alan

Bonne question ... cela pourrait l'expliquer: stackoverflow.com/questions/9778887/… . Personnellement, j'ai utilisé cette fonction pour déboguer les requêtes Doctrine, et je pense que Doctrine utilise des paramètres numérotés plutôt que nommés, donc je n'ai pas remarqué ce problème. J'ai mis à jour la fonction pour qu'elle fonctionne avec ou sans les deux points principaux maintenant.
Matt Browne

notez que cette solution remplace :name_longpar :name. Au moins si :namevient avant :name_long. Les instructions préparées par MySQL peuvent gérer cela correctement, alors ne vous laissez pas embrouiller.
Zim84

8

Non. Les requêtes PDO ne sont pas préparées côté client. PDO envoie simplement la requête SQL et les paramètres au serveur de base de données. La base de données est ce que fait la substitution (des ?'s). Vous avez deux options:

  • Utilisez la fonction de journalisation de votre base de données (mais même dans ce cas, elle est normalement affichée sous la forme de deux instructions distinctes (c'est-à-dire «non final») au moins avec Postgres)
  • Sortez la requête SQL et les paramètres et reconstituez-les vous-même

Je n'ai jamais pensé à vérifier le journal de la base de données. Je fouille dans le répertoire MySQL et je ne vois aucun fichier journal, mais peut-être que la journalisation est une option que je dois activer quelque part.
Nathan Long

Oui, vous devez l'activer. Je ne connais pas les détails mais par défaut, il n'enregistre pas toutes les requêtes.
ryeguy

5

presque rien n'a été dit sur l'affichage des erreurs sauf vérifier les journaux d'erreurs, mais il existe une fonctionnalité plutôt utile:

<?php
/* Provoke an error -- bogus SQL syntax */
$stmt = $dbh->prepare('bogus sql');
if (!$stmt) {
    echo "\PDO::errorInfo():\n";
    print_r($dbh->errorInfo());
}
?>

( lien source )

il est clair que ce code peut être modifié pour être utilisé comme message d'exception ou tout autre type de gestion d'erreur


2
C'est faux. PDO est suffisamment intelligent pour rendre ce code inutile. Dites-lui simplement de lancer des exceptions sur les erreurs. PHP fera le reste, bien mieux que cette fonction limitée. En outre, s'il vous plaît , ne pas apprendre à imprimer toutes les erreurs directement dans le navigateur. Il existe de meilleures façons.
Votre bon sens

3
c'est la documentation officielle, et bien sûr personne n'allait imprimer cette erreur en production, encore une fois, c'est un exemple du site officiel (php.net), voir le lien ci-dessous l'exemple de code. Et bien sûr, il est préférable d'utiliser des paramètres supplémentaires $ db-> setAttribute (PDO :: ATTR_ERRMODE, PDO :: ERRMODE_EXCEPTION) dans l'instanciation PDO mais malheureusement vous ne pouvez pas avoir accès à ce code
Zippp

4

par exemple, vous avez cette instruction pdo:

$query="insert into tblTest (field1, field2, field3)
values (:val1, :val2, :val3)";
$res=$db->prepare($query);
$res->execute(array(
  ':val1'=>$val1,
  ':val2'=>$val2,
  ':val3'=>$val3,
));

maintenant vous pouvez obtenir la requête exécutée en définissant un tableau comme celui-ci:

$assoc=array(
  ':val1'=>$val1,
  ':val2'=>$val2,
  ':val3'=>$val3,
);
$exQuery=str_replace(array_keys($assoc), array_values($assoc), $query);
echo $exQuery;

1
A travaillé pour moi. Vous avez une erreur dans le deuxième exemple de code: ));devrait être );(un seul crochet rond).
Jasom Dotnet

2

En cherchant sur Internet, j'ai trouvé cela comme une solution acceptable. Une classe différente est utilisée à la place des PDO et les fonctions PDO sont appelées via des appels de fonctions magiques. Je ne suis pas sûr que cela crée de sérieux problèmes de performances. Mais il peut être utilisé jusqu'à ce qu'une fonction de journalisation sensible soit ajoutée à PDO.

Ainsi, selon ce fil , vous pouvez écrire un wrapper pour votre connexion PDO qui peut enregistrer et lancer une exception lorsque vous obtenez une erreur.

Voici un exemple simple:

class LoggedPDOSTatement extends PDOStatement    {

function execute ($array)    {
    parent::execute ($array);
    $errors = parent::errorInfo();
    if ($errors[0] != '00000'):
        throw new Exception ($errors[2]);
    endif;
  }

}

vous pouvez donc utiliser cette classe au lieu de PDOStatement:

$this->db->setAttribute (PDO::ATTR_STATEMENT_CLASS, array ('LoggedPDOStatement', array()));

Voici une implémentation de décorateur PDO mentionnée:

class LoggedPDOStatement    {

function __construct ($stmt)    {
    $this->stmt = $stmt;
}

function execute ($params = null)    {
    $result = $this->stmt->execute ($params); 
    if ($this->stmt->errorCode() != PDO::ERR_NONE):
        $errors = $this->stmt->errorInfo();
        $this->paint ($errors[2]);
    endif;
    return $result;
}

function bindValue ($key, $value)    {
    $this->values[$key] = $value;    
    return $this->stmt->bindValue ($key, $value);
}

function paint ($message = false)    {
    echo '<pre>';
    echo '<table cellpadding="5px">';
    echo '<tr><td colspan="2">Message: ' . $message . '</td></tr>';
    echo '<tr><td colspan="2">Query: ' . $this->stmt->queryString . '</td></tr>';
    if (count ($this->values) > 0):
    foreach ($this->values as $key => $value):
    echo '<tr><th align="left" style="background-color: #ccc;">' . $key . '</th><td>' . $value . '</td></tr>';
    endforeach;
    endif;
    echo '</table>';
    echo '</pre>';
}

function __call ($method, $params)    {
    return call_user_func_array (array ($this->stmt, $method), $params); 
}

}

2

Pour connecter MySQL dans WAMP , vous devrez éditer le my.ini (par exemple sous wamp \ bin \ mysql \ mysql5.6.17 \ my.ini)

et ajouter à [mysqld]:

general_log = 1
general_log_file="c:\\tmp\\mysql.log"

2

Voici une fonction que j'ai créée pour renvoyer une requête SQL avec des paramètres "résolus".

function paramToString($query, $parameters) {
    if(!empty($parameters)) {
        foreach($parameters as $key => $value) {
            preg_match('/(\?(?!=))/i', $query, $match, PREG_OFFSET_CAPTURE);
            $query = substr_replace($query, $value, $match[0][1], 1);
        }
    }
    return $query;
    $query = "SELECT email FROM table WHERE id = ? AND username = ?";
    $values = [1, 'Super'];

    echo paramToString($query, $values);

En supposant que vous exécutez comme ça

$values = array(1, 'SomeUsername');
$smth->execute($values);

Cette fonction n'ajoute PAS de guillemets aux requêtes mais fait le travail pour moi.


J'ai ajouté ceci:if (is_string($value)) { $value = "'".$value."'"; }
Jurgen Dictus

0

Le problème que j'ai eu avec la solution pour attraper les exemptions PDO à des fins de débogage est qu'elle n'a attrapé que les exemptions PDO (duh), mais n'a pas attrapé les erreurs de syntaxe qui ont été enregistrées comme des erreurs php (je ne sais pas pourquoi, mais " pourquoi "est sans rapport avec la solution). Tous mes appels PDO proviennent d'une seule classe de modèle de table que j'ai étendue pour toutes mes interactions avec toutes les tables ... cela compliquait les choses lorsque j'essayais de déboguer du code, car l'erreur enregistrerait la ligne de code php où mon appel d'exécution était appelé, mais ne m'a pas dit d'où l'appel était en fait. J'ai utilisé le code suivant pour résoudre ce problème:

/**
 * Executes a line of sql with PDO.
 * 
 * @param string $sql
 * @param array $params
 */
class TableModel{
    var $_db; //PDO connection
    var $_query; //PDO query

    function execute($sql, $params) { 
        //we're saving this as a global, so it's available to the error handler
        global $_tm;
        //setting these so they're available to the error handler as well
        $this->_sql = $sql;
        $this->_paramArray = $params;            

        $this->_db->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_EXCEPTION);
        $this->_query = $this->_db->prepare($sql);

        try {
            //set a custom error handler for pdo to catch any php errors
            set_error_handler('pdoErrorHandler');

            //save the table model object to make it available to the pdoErrorHandler
            $_tm = $this;
            $this->_query->execute($params);

            //now we restore the normal error handler
            restore_error_handler();
        } catch (Exception $ex) {
            pdoErrorHandler();
            return false;
        }            
    }
}

Ainsi, le code ci-dessus détecte À LA FOIS les exceptions PDO ET les erreurs de syntaxe php et les traite de la même manière. Mon gestionnaire d'erreurs ressemble à ceci:

function pdoErrorHandler() {
    //get all the stuff that we set in the table model
    global $_tm;
    $sql = $_tm->_sql;
    $params = $_tm->_params;
    $query = $tm->_query;

    $message = 'PDO error: ' . $sql . ' (' . implode(', ', $params) . ") \n";

    //get trace info, so we can know where the sql call originated from
    ob_start();
    debug_backtrace(); //I have a custom method here that parses debug backtrace, but this will work as well
    $trace = ob_get_clean();

    //log the error in a civilized manner
    error_log($message);

    if(admin(){
        //print error to screen based on your environment, logged in credentials, etc.
        print_r($message);
    }
}

Si quelqu'un a de meilleures idées sur la façon d'obtenir des informations pertinentes pour mon gestionnaire d'erreurs que de définir le modèle de table en tant que variable globale, je serais heureux de l'entendre et de modifier mon code.


0

ce code fonctionne très bien pour moi:

echo str_replace(array_keys($data), array_values($data), $query->queryString);

N'oubliez pas de remplacer $ data et $ query par vos noms


0

j'utilise cette classe pour déboguer PDO (avec Log4PHP )

<?php

/**
 * Extends PDO and logs all queries that are executed and how long
 * they take, including queries issued via prepared statements
 */
class LoggedPDO extends PDO
{

    public static $log = array();

    public function __construct($dsn, $username = null, $password = null, $options = null)
    {
        parent::__construct($dsn, $username, $password, $options);
    }

    public function query($query)
    {
        $result = parent::query($query);
        return $result;
    }

    /**
     * @return LoggedPDOStatement
     */
    public function prepare($statement, $options = NULL)
    {
        if (!$options) {
            $options = array();
        }
        return new \LoggedPDOStatement(parent::prepare($statement, $options));
    }
}

/**
 * PDOStatement decorator that logs when a PDOStatement is
 * executed, and the time it took to run
 * @see LoggedPDO
 */
class LoggedPDOStatement
{

    /**
     * The PDOStatement we decorate
     */
    private $statement;
    protected $_debugValues = null;

    public function __construct(PDOStatement $statement)
    {
        $this->statement = $statement;
    }

    public function getLogger()
    {
        return \Logger::getLogger('PDO sql');
    }

    /**
     * When execute is called record the time it takes and
     * then log the query
     * @return PDO result set
     */
    public function execute(array $params = array())
    {
        $start = microtime(true);
        if (empty($params)) {
            $result = $this->statement->execute();
        } else {
            foreach ($params as $key => $value) {
                $this->_debugValues[$key] = $value;
            }
            $result = $this->statement->execute($params);
        }

        $this->getLogger()->debug($this->_debugQuery());

        $time = microtime(true) - $start;
        $ar = (int) $this->statement->rowCount();
        $this->getLogger()->debug('Affected rows: ' . $ar . ' Query took: ' . round($time * 1000, 3) . ' ms');
        return $result;
    }

    public function bindValue($parameter, $value, $data_type = false)
    {
        $this->_debugValues[$parameter] = $value;
        return $this->statement->bindValue($parameter, $value, $data_type);
    }

    public function _debugQuery($replaced = true)
    {
        $q = $this->statement->queryString;

        if (!$replaced) {
            return $q;
        }

        return preg_replace_callback('/:([0-9a-z_]+)/i', array($this, '_debugReplace'), $q);
    }

    protected function _debugReplace($m)
    {
        $v = $this->_debugValues[$m[0]];

        if ($v === null) {
            return "NULL";
        }
        if (!is_numeric($v)) {
            $v = str_replace("'", "''", $v);
        }

        return "'" . $v . "'";
    }

    /**
     * Other than execute pass all other calls to the PDOStatement object
     * @param string $function_name
     * @param array $parameters arguments
     */
    public function __call($function_name, $parameters)
    {
        return call_user_func_array(array($this->statement, $function_name), $parameters);
    }
}

0

J'ai créé un projet / référentiel moderne chargé par Composer pour exactement cela ici:

pdo-debug

Trouvez la page d' accueil GitHub du projet ici , voir un article de blog l'expliquant ici . Une ligne à ajouter dans votre composer.json, puis vous pouvez l'utiliser comme ceci:

echo debugPDO($sql, $parameters);

$ sql est l'instruction SQL brute, $ parameters est un tableau de vos paramètres: la clé est le nom de l'espace réservé (": user_id") ou le numéro du paramètre sans nom ("?"), la valeur est .. eh bien, le valeur.

La logique derrière: Ce script gradera simplement les paramètres et les remplacera dans la chaîne SQL fournie. Super simple, mais super efficace pour 99% de vos cas d'utilisation. Remarque: Ceci est juste une émulation de base, pas un vrai débogage PDO (car cela n'est pas possible car PHP envoie du SQL brut et des paramètres au serveur MySQL séparés).

Un grand merci à bigwebguy et Mike du thread StackOverflow Obtenir la chaîne de requête SQL brute de PDO pour avoir écrit essentiellement la fonction principale derrière ce script. Dédicace!


0

Comment déboguer les requêtes de base de données PDO mysql dans Ubuntu

TL; DR Enregistrez toutes vos requêtes et suivez le journal mysql.

Ces instructions concernent mon installation d'Ubuntu 14.04. Émettez la commande lsb_release -apour obtenir votre version. Votre installation peut être différente.

Activer la connexion dans mysql

  1. Accédez à la ligne cmd de votre serveur de développement
  2. Changez de répertoire cd /etc/mysql. Vous devriez voir un fichier appelé my.cnf. C'est le fichier que nous allons changer.
  3. Vérifiez que vous êtes au bon endroit en tapant cat my.cnf | grep general_log. Cela filtre le my.cnffichier pour vous. Vous devriez voir deux entrées: #general_log_file = /var/log/mysql/mysql.log&& #general_log = 1.
  4. Décommentez ces deux lignes et enregistrez via l'éditeur de votre choix.
  5. Redémarrer MySQL: sudo service mysql restart.
  6. Vous devrez peut-être redémarrer votre serveur Web également. (Je ne me souviens pas de la séquence que j'ai utilisée). Pour mon installation, qui est Nginx: sudo service nginx restart.

Bon travail! Vous êtes prêt. Il ne vous reste plus qu'à terminer le fichier journal afin de voir les requêtes PDO effectuées par votre application en temps réel.

Tail le journal pour voir vos requêtes

Entrez cette cmd tail -f /var/log/mysql/mysql.log.

Votre sortie ressemblera à ceci:

73 Connect  xyz@localhost on your_db
73 Query    SET NAMES utf8mb4
74 Connect  xyz@localhost on your_db
75 Connect  xyz@localhost on your_db
74 Quit 
75 Prepare  SELECT email FROM customer WHERE email=? LIMIT ?
75 Execute  SELECT email FROM customer WHERE email='a@b.co' LIMIT 5
75 Close stmt   
75 Quit 
73 Quit 

Toute nouvelle requête effectuée par votre application apparaîtra automatiquement , tant que vous continuerez à suivre le journal. Pour sortir de la queue, frappez cmd/ctrl c.

Remarques

  1. Attention: ce fichier journal peut devenir énorme. Je ne l'exécute que sur mon serveur de développement.
  2. Le fichier journal devient trop volumineux? Tronquez-le. Cela signifie que le fichier reste, mais que le contenu est supprimé. truncate --size 0 mysql.log.
  3. Cool que le fichier journal répertorie les connexions mysql. Je sais que l'un d'entre eux provient de mon ancien code mysqli à partir duquel je suis en train de faire la transition. Le troisième provient de ma nouvelle connexion PDO. Cependant, je ne sais pas d'où vient la seconde. Si vous connaissez un moyen rapide de le trouver, faites-le moi savoir.

Crédit et merci

Grand cri à la réponse de Nathan Long ci-dessus pour l'inspiration de comprendre cela sur Ubuntu. Aussi à dikirill pour son commentaire sur le post de Nathan qui m'a conduit à cette solution.

Je t'aime stackoverflow!


0

Dans l'environnement Debian NGINX, j'ai fait ce qui suit.

Allez /etc/mysql/mysql.conf.dmodifier mysqld.cnfsi vous trouvez, log-error = /var/log/mysql/error.logajoutez les 2 lignes suivantes ci-dessous.

general_log_file        = /var/log/mysql/mysql.log
general_log             = 1

Pour voir les journaux, allez /var/log/mysqlet tail -f mysql.log

N'oubliez pas de commenter ces lignes une fois que vous avez terminé le débogage si vous êtes dans un environnement de production, supprimez mysql.logcar ce fichier journal augmentera rapidement et peut être énorme.


tout le monde n'utilise pas mysql.
Point-virgule
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.