pt-query-digestp - En ligne dans le Cloud

PROGRAMME:

Nom

pt-query-digest - Analyse les requêtes MySQL à partir des journaux, processlist et tcpdump.

SYNOPSIS

Utilisation : pt-query-digest [OPTIONS] [FILES] [DSN]

pt-query-digest analyse les requêtes MySQL à partir de fichiers journaux lents, généraux et binaires. Ça peut
analyser également les requêtes de "SHOW PROCESSLIST" et les données du protocole MySQL de tcpdump. Par
par défaut, les requêtes sont regroupées par empreinte digitale et signalées par ordre décroissant de temps de requête
(c'est-à-dire les requêtes les plus lentes en premier). Si aucun "FILES" n'est donné, l'outil lit "STDIN". le
"DSN" optionnel est utilisé pour certaines options comme "--since" et "--until".

Signalez les requêtes les plus lentes de "slow.log":

pt-query-digest slow.log

Signalez les requêtes les plus lentes de la liste des processus sur host1 :

pt-query-digest --processlist h=hôte1

Capturez les données du protocole MySQL avec tcppdump, puis signalez les requêtes les plus lentes :

tcpdump -s 65535 -x -nn -q -tttt -i any -c 1000 port 3306 > mysql.tcp.txt

pt-query-digest --type tcpdump mysql.tcp.txt

Enregistrez les données de requête de "slow.log" vers host2 pour une révision ultérieure et une analyse des tendances :

pt-query-digest --review h=host2 --no-report slow.log

LES RISQUES

Percona Toolkit est mature, éprouvé dans le monde réel et bien testé, mais toutes les bases de données
outils peuvent présenter un risque pour le système et le serveur de base de données. Avant d'utiliser cet outil,
s'il te plaît:

· Lire la documentation de l'outil

· Revoir les "BUGS" connus de l'outil

· Tester l'outil sur un serveur hors production

· Sauvegardez votre serveur de production et vérifiez les sauvegardes

DESCRIPTION

pt-query-digest est un outil sophistiqué mais facile à utiliser pour analyser les requêtes MySQL. Ce
peut analyser les requêtes des journaux MySQL lents, généraux et binaires. (Les journaux binaires doivent d'abord être
converti en texte, voir "--type"). Il peut également utiliser "SHOW PROCESSLIST" et le protocole MySQL
données de tcpdump. Par défaut, l'outil signale les requêtes les plus lentes et
donc le plus important à optimiser. Des rapports plus complexes et personnalisés peuvent être
créé en utilisant des options telles que "--group-by", "--filter" et "--embedded-attributes".

L'analyse des requêtes est une bonne pratique qui doit être effectuée fréquemment. Pour rendre cela plus facile,
pt-query-digest a deux fonctionnalités : la révision des requêtes ("--review") et l'historique des requêtes
("--l'histoire"). Lorsque l'option "--review" est utilisée, toutes les requêtes uniques sont enregistrées dans un
base de données. Lorsque l'outil est réexécuté avec "--review", les requêtes marquées comme révisées dans le
base de données ne sont pas imprimés dans le rapport. Cela met en évidence les nouvelles requêtes qui doivent être
revu. Lorsque l'option "--history" est utilisée, les métriques de requête (temps de requête, temps de verrouillage,
etc.) pour chaque requête unique sont enregistrés dans la base de données. Chaque fois que l'outil est exécuté avec
"--history", plus les données historiques sont enregistrées, ce qui peut être utilisé pour la tendance et l'analyse
performances des requêtes au fil du temps.

CARACTÉRISTIQUES

pt-query-digest fonctionne sur les événements, qui sont une collection de paires clé-valeur appelées
les attributs. Vous reconnaîtrez immédiatement la plupart des attributs : "Query_time",
"Lock_time", et ainsi de suite. Vous pouvez simplement regarder un journal lent et les voir. Cependant, il y a
certains qui n'existent pas dans le journal lent, et les journaux lents peuvent en fait inclure différents types
d'attributs (par exemple, vous pouvez avoir un serveur avec les correctifs Percona).

Voir « RÉFÉRENCE DES ATTRIBUTS » vers la fin de cette documentation pour une liste des
Attributs spécifiques "--type". Une connaissance de ces attributs est nécessaire pour
travailler avec "--filter", "--ignore-attributes" et d'autres options liées aux attributs.

Avec l'utilisation créative de "--filter", vous pouvez créer de nouveaux attributs dérivés de l'existant
les attributs. Par exemple, pour créer un attribut appelé "Row_ratio" pour examiner le
ratio de "Rows_sent" à "Rows_examined", spécifiez un filtre comme :

--filter '($event->{Row_ratio} = $event->{Rows_sent} / ($event->{Rows_examined})) && 1'

L'astuce "&& 1" est nécessaire pour créer une syntaxe valide sur une ligne qui est toujours vraie, même si
l'affectation arrive à évaluer faux. Le nouvel attribut apparaîtra automatiquement dans
le résultat:

# Ratio rang 1.00 0.00 1 0.50 1 0.71 0.50

Les attributs créés de cette manière peuvent être spécifiés pour "--order-by" ou toute option qui nécessite
un attribut.

SORTIE

La valeur par défaut "--output" est un rapport d'analyse de requête. L'option "--[no]report" contrôle
si ce rapport est imprimé ou non. Parfois, vous voudrez peut-être analyser toutes les requêtes
mais supprimez le rapport, par exemple lorsque vous utilisez "--review" ou "--history".

Il y a un paragraphe pour chaque classe de requête analysée. Une "classe" de requêtes a toutes
la même valeur pour l'attribut "--group-by" qui est "fingerprint" par défaut. (Voir
"ATTRIBUTS".) Une empreinte digitale est une version abstraite du texte de la requête avec des littéraux
supprimé, l'espace blanc s'est effondré, et ainsi de suite. Le rapport est formaté de sorte qu'il est facile de
coller dans les e-mails sans emballage, et toutes les lignes de non-requête commencent par un commentaire, donc vous
pouvez l'enregistrer dans un fichier .sql et l'ouvrir dans votre éditeur de texte de coloration syntaxique préféré.
Il y a un profil de temps de réponse au début.

La sortie décrite ici est contrôlée par "--report-format". Cette option vous permet de
spécifier quoi imprimer et dans quel ordre. La sortie par défaut dans l'ordre par défaut est
décrit ici.

Le rapport, par défaut, commence par un paragraphe sur l'ensemble de l'analyse.
les informations sont très similaires à ce que vous verrez pour chaque classe de requêtes dans le journal, mais
il ne contient pas certaines informations qu'il serait trop coûteux de conserver globalement pour le
Analyse. Il contient également des statistiques sur l'exécution du code lui-même, telles que le processeur
et l'utilisation de la mémoire, la date et l'heure locales de l'exécution et une liste des fichiers d'entrée
lu/parsé.

Voici le profil de temps de réponse sur les événements. Il s'agit d'un très résumé
vue des événements uniques dans le rapport de requête détaillé qui suit. Il contient le
colonnes suivantes :

Colonne Signification
============ ====================================== =====================
Rang Le rang de la requête dans l'ensemble des requêtes analysées
ID de la requête L'empreinte de la requête
Temps de réponse Le temps de réponse total et le pourcentage du total global
Appels Le nombre de fois que cette requête a été exécutée
R/Call Le temps de réponse moyen par exécution
V/M Le rapport variance/moyenne du temps de réponse
Élément La requête distillée

Une dernière ligne dont le rang est affiché comme MISC contient des statistiques agrégées sur les requêtes qui
n'ont pas été inclus dans le rapport, en raison d'options telles que "--limit" et "--outliers". Pour
détails sur le ratio variance/moyenne, veuillez consulter
http://en.wikipedia.org/wiki/Index_of_dispersion.

Ensuite, le rapport de requête détaillé est imprimé. Chaque requête apparaît dans un paragraphe. Voici une
sample, légèrement reformaté pour que 'perldoc' n'enveloppe pas les lignes dans un terminal. le
ce qui suit sera un seul paragraphe, mais nous le diviserons pour le commentaire.

# Requête 2 : 0.01 QPS, 0.02x conc, ID 0xFDEA8D2993C9CAF3 à l'octet 160665

Cette ligne identifie le numéro d'ordre de la requête dans l'ordre de tri spécifié par
"--commandé par". Ensuite, il y a les requêtes par seconde et la simultanéité approximative pour
cette requête (calculée en fonction de l'intervalle de temps et du total Query_time). Ensuite, il y a
un identifiant de requête. Cet ID est une version hexadécimale de la somme de contrôle de la requête dans la base de données, si vous êtes
en utilisant "--review". Vous pouvez sélectionner les détails de la requête révisée dans la base de données avec un
requête comme "SELECT .... WHERE checksum=0xFDEA8D2993C9CAF3".

Si vous étudiez le rapport et souhaitez imprimer chaque échantillon d'un
requête, le "--filter" suivant peut être utile :

pt-query-digest lent.log \
--no-rapport \
--output journal lent \
--filter '$événement->{empreinte} \
&& make_checksum($event->{fingerprint}) eq "FDEA8D2993C9CAF3"'

Notez que vous devez supprimer le préfixe « 0x » de la somme de contrôle.

Enfin, au cas où vous voudriez trouver un échantillon de la requête dans le fichier journal, il y a l'octet
décalage où vous pouvez regarder. (Ce n'est pas toujours exact, en raison de certaines anomalies dans le
format de journal lent, mais il est généralement correct.) La position fait référence au pire échantillon, qui
nous en verrons plus ci-dessous.

Vient ensuite le tableau des métriques concernant cette classe de requêtes.

# pct total min max moy 95% stddev médian
# Compte 0 2
# Temps d'exécution 13 1105s 552s 554s 553s 554s 2s 553s
# Temps de verrouillage 0 216us 99us 117us 108us 117us 12us 108us
# Lignes envoyées 20 6.26M 3.13M 3.13M 3.13M 3.13M 12.73 3.13M
# Examen de lignes 0 6.26M 3.13M 3.13M 3.13M 3.13M 12.73 3.13M

La première ligne correspond aux en-têtes de colonne du tableau. Le pourcentage est le pourcentage de la
total pour l'ensemble de l'analyse, et le total est la valeur réelle du
métrique. Par exemple, dans ce cas, nous pouvons voir que la requête s'est exécutée 2 fois, ce qui est
13% du nombre total de requêtes dans le fichier. Les colonnes min, max et avg sont auto-
explicatif. La colonne 95 % indique le 95e centile ; 95% des valeurs sont inférieures ou
égal à cette valeur. L'écart type vous montre à quel point les valeurs sont regroupées.
L'écart type et la médiane sont tous deux calculés à partir du 95e centile, en écartant
les valeurs extrêmement grandes.

Les statistiques stddev, médiane et 95e centile sont approximatives. Statistiques exactes
nécessitent de conserver toutes les valeurs vues, de les trier et de faire des calculs dessus. Cela utilise
beaucoup de mémoire. Pour éviter cela, nous gardons 1000 seaux, chacun d'eux 5% plus grand que celui
avant, allant de .000001 jusqu'à un très grand nombre. Quand nous voyons une valeur, nous incrémentons
le seau dans lequel il tombe. Ainsi, nous avons une mémoire fixe par classe de requêtes. le
L'inconvénient est l'imprécision, qui est généralement de l'ordre de 5 %.

Ensuite, nous avons des statistiques sur les utilisateurs, les bases de données et la plage de temps pour la requête.

# Utilisateurs 1 utilisateur1
# Bases de données 2 db1(1), db2(1)
# Période 2008-11-26 04:55:18 au 2008-11-27 00:15:15

Les utilisateurs et les bases de données sont affichés sous forme de nombre de valeurs distinctes, suivi des valeurs.
S'il n'y en a qu'un, il est affiché seul ; s'il y en a beaucoup, nous montrons chacun des plus
fréquentes, suivies du nombre de fois où elle apparaît.

# Distribution de l'heure de la requête
# 1nous
# 10nous
# 100nous
# 1 ms
# 10 ms #####
# 100ms #####################
# 1s ##########
# 10s+

Les temps d'exécution montrent un graphique logarithmique de clustering temporel. Chaque requête va dans un
des « seaux » et est compté. Les seaux sont des puissances de dix. Le premier seau est
toutes les valeurs dans la "plage de microseconde unique" - c'est-à-dire moins de 10us. La seconde est
« des dizaines de microsecondes », qui vont de 10 us à (mais non compris) 100 us ; etc.
L'attribut graphique peut être modifié en spécifiant "--report-histogram" mais est limité à
attributs basés sur le temps.

# Les tables
# AFFICHER L'ÉTAT DE LA TABLE COMME 'table1'\G
# AFFICHER CRÉER UNE TABLE `table1`\G
# EXPLIQUE
SELECT * FROM table1\G

Cette section est pratique : si vous essayez d'optimiser les requêtes que vous voyez dans le
journal lent, vous voudrez probablement examiner la structure et la taille de la table. Ce sont des copies-et-
commandes prêtes à coller pour le faire.

Enfin, nous voyons un échantillon des requêtes dans cette classe de requêtes. Ce n'est pas un hasard
goûter. C'est la requête qui a le moins bien fonctionné, selon l'ordre de tri donné par
"--commandé par". Vous verrez normalement une ligne commentée "# EXPLAIN" juste avant, donc vous
peut copier-coller la requête pour examiner son plan EXPLAIN. Mais pour les requêtes non SELECT qui
n'est pas possible de le faire, donc l'outil essaie de transformer la requête en une requête à peu près équivalente
requête SELECT, et l'ajoute ci-dessous.

Si vous souhaitez trouver cet exemple d'événement dans le journal, utilisez le décalage mentionné ci-dessus et
quelque chose comme ce qui suit :

queue -c + /chemin/vers/fichier | diriger

Voir aussi "--report-format".

QUERY Avis

Une requête "--review" est le processus de stockage de toutes les empreintes de requête analysées. Cette
présente plusieurs avantages:

· Vous pouvez ajouter des métadonnées aux classes de requêtes, comme les marquer pour le suivi, ajouter
notes aux requêtes, ou en les marquant avec un ID de problème pour votre système de suivi des problèmes.

· Vous pouvez vous référer aux valeurs stockées lors des exécutions suivantes afin de savoir si vous avez
vu une requête avant. Cela peut vous aider à réduire le travail en double.

· Vous pouvez stocker des données historiques telles que le nombre de lignes, les heures de requête et généralement
tout ce que vous pouvez voir dans le rapport.

Pour utiliser cette fonctionnalité, vous exécutez pt-query-digest avec l'option "--review". il stockera
les empreintes digitales et autres informations dans le tableau que vous spécifiez. La prochaine fois que vous l'exécutez
avec la même option, il effectuera les opérations suivantes :

· Il ne vous montrera pas les requêtes que vous avez déjà examinées. Une requête est considérée comme
déjà examiné si vous avez défini une valeur pour la colonne "reviewed_by". (Si tu veux
voir les requêtes que vous avez déjà examinées, utilisez l'option "--report-all".)

· Les requêtes que vous avez examinées et qui n'apparaissent pas dans la sortie entraîneront des lacunes dans la
séquence de numéros de requête dans la première ligne de chaque paragraphe. Et la valeur que vous avez
spécifié pour "--limit" sera toujours honoré. Donc, si vous avez examiné toutes les requêtes dans
le top 10 et vous demandez le top 10, vous ne verrez rien dans la sortie.

· Si vous souhaitez voir les requêtes que vous avez déjà examinées, vous pouvez spécifier
"--rapport-tout". Ensuite, vous verrez la sortie d'analyse normale, mais vous verrez également le
informations du tableau de revue, juste en dessous du graphique du temps d'exécution. Par example,

# Vérifier les informations
# commentaires : très mauvaise sous-requête IN(), corrigée bientôt !
# premier_vu : 2008-12-01 11:48:57
# jira_ticket : 1933
# dernière_vue : 2008-12-18 11:49:07
# priorité : élevée
# revu_par : xaprb
# revu_le: 2008-12-18 15:03:11

Ces métadonnées sont utiles car, au fur et à mesure que vous analysez vos requêtes, vous obtenez vos commentaires
intégré directement dans le rapport.

EMPREINTES

Une empreinte de requête est la forme abstraite d'une requête, qui permet de regrouper
requêtes similaires ensemble. L'abstraction d'une requête supprime les valeurs littérales, normalise
espace, et ainsi de suite. Par exemple, considérons ces deux requêtes :

SELECT nom, mot de passe FROM utilisateur WHERE id='12823';
sélectionnez le nom, le mot de passe de l'utilisateur
où id=5 ;

Ces deux requêtes prendront les empreintes digitales pour

sélectionnez le nom, le mot de passe de l'utilisateur où id=?

Une fois l'empreinte de la requête connue, on peut alors parler d'une requête comme si elle
représente toutes les requêtes similaires.

Ce que fait "pt-query-digest" est analogue à une instruction GROUP BY en SQL. (Mais notez que
« plusieurs colonnes » ne définit pas un regroupement multi-colonnes ; il définit plusieurs rapports !)
Si votre ligne de commande ressemble à ceci,

pt-requête-digest \
--group-by empreinte digitale \
--order-by Query_time:somme \
--limite 10 \
lent.log

Le pseudo-SQL correspondant ressemble à ceci :

SELECTIONNER LE PIRE(requête BY Query_time), SUM(Query_time), ...
DE /chemin/vers/slow.log
GROUPER PAR EMPREINTE DIGITALE (requête)
COMMANDE PAR SOMME (Query_time) DESC
LIMITE 10

Vous pouvez également utiliser la valeur « distiller », qui est une sorte de super empreinte digitale. Voir
"--group-by" pour en savoir plus.

Les empreintes digitales des requêtes s'adaptent à de nombreux cas particuliers, qui se sont avérés nécessaires dans le
monde réel. Par exemple, une liste "IN" avec 5 littéraux est vraiment équivalente à une avec 4
littéraux, de sorte que les listes de littéraux sont réduites en un seul. Si vous trouvez quelque chose qui
n'est pas correctement identifié, veuillez soumettre un rapport de bogue avec un cas de test reproductible.

Voici une liste des transformations lors de la prise d'empreintes digitales, qui n'est peut-être pas exhaustive :

· Regrouper toutes les requêtes SELECT de mysqldump, même si elles sont contre différentes
les tables. La même chose s'applique à toutes les requêtes de pt-table-checksum.

· Raccourcir les instructions INSERT à valeurs multiples en une seule VALEURS() liste.

· Supprimer les commentaires.

· Abrégez les bases de données dans les instructions USE, de sorte que toutes les instructions USE soient regroupées.

· Remplacez tous les littéraux, tels que les chaînes entre guillemets. Pour plus d'efficacité, le code qui remplace
les nombres littéraux sont quelque peu non sélectifs et peuvent remplacer certaines choses par des nombres
alors qu'ils ne le sont vraiment pas. Les littéraux hexadécimaux sont également remplacés. NULL est traité comme
un littéral. Les nombres intégrés dans les identifiants sont également remplacés, de sorte que les tables nommées
de la même manière, les empreintes digitales seront les mêmes (par exemple, users_2009 et users_2010
prendra les empreintes digitales à l'identique).

· Réduisez tous les espaces en un seul espace.

· Minuscule la requête entière.

· Remplacez tous les littéraux à l'intérieur de DANS() et VALEURS() listes avec un seul espace réservé,
quelle que soit la cardinalité.

· Réduisez plusieurs requêtes UNION identiques en une seule.

OPTIONS

Cet outil accepte des arguments de ligne de commande supplémentaires. Se référer au "SYNOPSIS" et à l'utilisation
informations pour plus de détails.

--demander-passer
Demander un mot de passe lors de la connexion à MySQL.

--attribut-alias
type : tableau ; par défaut : db|Schéma

Liste des attributs|alias, etc.

Certains attributs ont plusieurs noms, comme db et Schema. Si un événement n'a pas
l'attribut principal, pt-query-digest, recherche un attribut d'alias. S'il trouve un
alias, il crée l'attribut principal avec la valeur de l'attribut d'alias et supprime
l'attribut alias.

Si l'événement a l'attribut principal, tous les attributs d'alias sont supprimés.

Cela permet de simplifier les attributs d'événement de sorte que, par exemple, il n'y aura pas de rapport
lignes pour db et Schema.

--attribute-valeur-limite
tapez : entier ; par défaut : 4294967296

Une limite de validité pour les valeurs d'attribut.

Cette option traite des bogues dans la fonctionnalité de journalisation lente qui provoque des valeurs élevées pour
les attributs. Si la valeur de l'attribut est supérieure à cela, la dernière valeur vue pour
cette classe de requête est utilisée à la place.

--jeu de caractères
forme courte : -A ; type : chaîne

Jeu de caractères par défaut. Si la valeur est utf8, définit le binmode de Perl sur STDOUT sur utf8,
passe l'option mysql_enable_utf8 à DBD::mysql et exécute SET NAMES UTF8 après
connexion à MySQL. Toute autre valeur définit binmode sur STDOUT sans la couche utf8,
et exécute SET NAMES après la connexion à MySQL.

--config
type : tableau

Lisez cette liste de fichiers de configuration séparés par des virgules ; si spécifié, ce doit être le premier
option sur la ligne de commande.

--[no]continuer-sur-erreur
par défaut : oui

Continuez l'analyse même s'il y a une erreur. L'outil ne durera pas éternellement : il
s'arrête une fois qu'un processus provoque 100 erreurs, auquel cas il y a probablement un bogue dans le
outil ou l'entrée est invalide.

--[no]créer-historique-table
par défaut : oui

Créez la table "--history" si elle n'existe pas.

Cette option provoque la création de la table spécifiée par "--history" avec la valeur par défaut
structure montrée dans la documentation pour "--history".

--[no]créer une table de révision
par défaut : oui

Créez la table "--review" si elle n'existe pas.

Cette option provoque la création de la table spécifiée par "--review" avec la valeur par défaut
structure montrée dans la documentation pour "--review".

--démoniser
Fourchette à l'arrière-plan et détacher de la coque. Systèmes d'exploitation POSIX uniquement.

--base de données
forme courte : -D ; type : chaîne

Connectez-vous à cette base de données.

--defaults-fichier
forme courte : -F ; type : chaîne

Ne lisez que les options mysql du fichier donné. Vous devez donner un chemin d'accès absolu.

--attributs-embedded
type : tableau

Deux modèles de regex Perl pour capturer les pseudo-attributs intégrés dans les requêtes.

Les attributs intégrés peuvent être des paires attribut-valeur spéciales que vous avez masquées dans
commentaires. La première expression régulière doit correspondre à l'ensemble des attributs (au cas où il
sont multiples). La deuxième regex doit correspondre et capturer les paires attribut-valeur de
la première regex.

Par exemple, supposons que votre requête ressemble à ce qui suit :

SELECT * des utilisateurs -- fichier : /login.php, ligne : 493 ;

Vous pouvez exécuter pt-query-digest avec l'option suivante :

pt-query-digest --embedded-attributes ' -- .*','(\w+): ([^\,]+)'

La première expression régulière capture l'intégralité du commentaire :

" -- fichier : /login.php, ligne : 493 ;"

Le second le divise en paires attribut-valeur et les ajoute à l'événement :

VALEUR D'ATTRIBUT
========= ===========
fichier /login.php
ligne 493

REMARQUE: Toutes les virgules dans les motifs regex doivent être échappées avec \ sinon le motif
cassera.

--plage-attendue
type : tableau ; par défaut : 5,10

Expliquez les éléments lorsqu'il y en a plus ou moins que prévu.

Définit le nombre d'éléments attendus dans le rapport donné par "--[no]report",
comme contrôlé par "--limit" et "--outliers". S'il y a plus ou moins d'articles dans le
rapport, chacun expliquera pourquoi il a été inclus.

--Explique
tapez : DSN

Exécutez EXPLAIN pour l'exemple de requête avec ce DSN et imprimez les résultats.

Cela ne fonctionne que lorsque "--group-by" inclut une empreinte digitale. Cela provoque pt-query-digest à
exécutez EXPLAIN et incluez la sortie dans le rapport. Pour des raisons de sécurité, les requêtes qui s'affichent
avoir une sous-requête que EXPLAIN exécutera ne sera pas EXPLAINed. Ce sont généralement
requêtes "table dérivée" de la forme

sélectionner ... à partir de ( sélectionner .... ) der;

Les résultats EXPLAIN sont imprimés dans un format vertical complet dans le rapport d'événement, qui
apparaît à la fin de chaque rapport d'événement dans un style vertical ("\G") tout comme MySQL
l'imprime.

--filtre
type : chaîne

Ignorez les événements pour lesquels ce code Perl ne renvoie pas vrai.

Cette option est une chaîne de code Perl ou un fichier contenant du code Perl qui est compilé
dans un sous-programme avec un argument : $event. Ceci est un hashref. Si la valeur donnée
est un fichier lisible, alors pt-query-digest lit le fichier entier et utilise son contenu
comme code. Le fichier ne doit pas contenir de shebang (#!/usr/bin/perl) ligne.

Si le code renvoie true, la chaîne de rappels continue ; sinon ça se termine. Les
code est la dernière instruction du sous-programme autre que "return $event". Les
le modèle de sous-programme est :

sub { $événement = décalage; filtre && return $event; }

Les filtres donnés sur la ligne de commande sont entourés de parenthèses comme "( filter
)". Pour les filtres multilignes complexes, vous devez mettre le code dans un fichier afin qu'il
ne pas être mis entre parenthèses. Dans tous les cas, le filtre doit produire syntaxiquement
code valide étant donné le modèle. Par exemple, une branche if-else donnée sur la commande
la ligne ne serait pas valide :

--filter 'if () { } else { }' # FAUX

Comme il est donné sur la ligne de commande, la branche if-else serait enveloppée à l'intérieur
parenthèses qui n'est pas syntaxiquement valide. Donc pour accomplir quelque chose de plus complexe
comme cela nécessiterait de mettre le code dans un fichier, par exemple filter.txt :

mon $event_ok; si (...) { $event_ok=1; } else { $event_ok=0; } $event_ok

Ensuite, spécifiez "--filter filter.txt" pour lire le code de filter.txt.

Si le code du filtre ne se compile pas, pt-query-digest mourra avec une erreur. Si la
le code du filtre se compile, une erreur peut toujours se produire au moment de l'exécution si le code essaie de le faire
quelque chose ne va pas (comme le motif correspond à une valeur indéfinie). pt-query-digest ne
fournissez toutes les garanties afin de coder avec soin !

Un exemple de filtre qui supprime tout sauf les instructions SELECT :

--filter '$event->{arg} =~ m/^select/i'

Ceci est compilé dans un sous-programme comme suit :

sub { $événement = décalage; ( $event->{arg} =~ m/^select/i ) && return $event; }

Il est permis que le code ait des effets secondaires (pour modifier $event).

Voir « RÉFÉRENCE DES ATTRIBUTS » pour une liste des attributs communs et spécifiques au « -type ».

Voici d'autres exemples de code de filtre :

L'hôte/l'IP correspond à domaine.com
--filter '($event->{host} || $event->{ip} || "") =~ m/domain.com/'

Parfois, MySQL enregistre l'hôte où l'adresse IP est attendue. Par conséquent, nous vérifions les deux.

L'utilisateur correspond à john
--filter '($event->{user} || "") =~ m/john/'

Plus d'un avertissement
--filter '($événement->{Warning_count} || 0) > 1'

La requête effectue une analyse complète de la table ou une jointure complète
--filter '(($event->{Full_scan} || "") eq "Oui") || (($événement->{Full_join} || "")
éq "Oui")'

La requête n'a pas été servie à partir du cache de requêtes
--filter '($événement->{QC_Hit} || "") eq "Non"'

La requête est de 1 Mo ou plus
--filter '$événement->{octets} >= 1_048_576'

Puisque "--filter" vous permet de modifier $event, vous pouvez l'utiliser pour faire d'autres choses, comme
créer de nouveaux attributs. Voir "ATTRIBUTS" pour un exemple.

--par groupe
type : tableau ; par défaut : empreinte digitale

Par quel attribut les événements doivent-ils être regroupés.

En général, vous pouvez regrouper les requêtes en classes en fonction de n'importe quel attribut de la requête,
comme « user » ou « db », qui vous indiquera par défaut quels utilisateurs et quelles bases de données
obtenir le plus de "Query_time". L'attribut par défaut, "empreinte digitale", regroupe des groupes similaires,
requêtes abstraites en classes ; voir ci-dessous et voir aussi " EMPREINTES DIGITALES ".

Un rapport est imprimé pour chaque valeur "--group-by" (sauf si "--no-report" est indiqué).
Par conséquent, "--group-by user,db" signifie "rapport sur les requêtes avec le même utilisateur et rapport
sur les requêtes avec la même base de données » ; cela ne signifie pas « rapport sur les requêtes avec le même utilisateur
et db." Voir aussi "SORTIE".

Chaque valeur doit avoir une valeur correspondante dans la même position dans "--order-by".
Cependant, l'ajout de valeurs à "--group-by" ajoutera automatiquement des valeurs à "--order-by",
Pour ta convenance.

Il existe plusieurs valeurs magiques qui provoquent une extraction de données supplémentaire avant
le regroupement a lieu :

empreinte digitale
Cela provoque l'empreinte des événements dans des requêtes abstraites sous une forme canonique,
qui est ensuite utilisé pour regrouper les événements dans une classe. Voir « EMPREINTES DIGITALES » pour
plus sur les empreintes digitales.

les tables
Cela provoque l'inspection des événements pour ce qui semble être des tables, puis
agrégé par cela. Notez qu'une requête qui contient deux ou plusieurs tables sera
compté autant de fois qu'il y a de tables ; donc une jointure contre deux tables comptera
le Query_time contre les deux tables.

distiller
C'est une sorte de super empreinte digitale qui réduit les requêtes en une suggestion
de ce qu'ils font, comme "INSERT SELECT table1 table2".

--Aidez-moi
Afficher l'aide et quitter.

--l'histoire
tapez : DSN

Enregistrez les métriques pour chaque classe de requête dans la table donnée. pt-query-digest enregistre la requête
métriques (temps de requête, temps de verrouillage, etc.) à cette table afin que vous puissiez voir comment les classes de requête
change avec le temps.

La table par défaut est "percona_schema.query_history". Spécifiez la base de données (D) et la table
(t) Options DSN pour remplacer la valeur par défaut. La base de données et la table sont automatiquement
créé à moins que "--no-create-history-table" ne soit spécifié (voir
"--[no]create-history-table").

pt-query-digest inspecte les colonnes de la table. La table doit avoir au moins le
colonnes suivantes :

CREATE TABLE query_review_history (
somme de contrôle BIGINT UNSIGNED NOT NULL,
exemple TEXTE NON NULL
);

Toutes les colonnes non mentionnées ci-dessus sont inspectées pour voir si elles suivent un certain nom
convention. La colonne est spéciale si le nom se termine par un trait de soulignement suivi d'un
de ces valeurs :

pct|moy|cnt|sum|min|max|pct_95|stddev|median|rank

Si la colonne se termine par l'une de ces valeurs, le préfixe est interprété comme le
attribut d'événement à stocker dans cette colonne, et le suffixe est interprété comme la métrique
à stocker. Par exemple, une colonne nommée "Query_time_min" sera utilisée pour stocker le
minimum "Query_time" pour la classe d'événements.

La table doit également avoir une clé primaire, mais cela dépend de vous, selon la façon dont vous
souhaitez stocker les données historiques. Nous suggérons d'ajouter les colonnes ts_min et ts_max et
en les faisant partie de la clé primaire avec la somme de contrôle. Mais vous pouvez aussi simplement
ajoutez une colonne ts_min et faites-en un type DATE, vous obtiendrez donc une ligne par classe de requêtes
par jour.

La définition de table suivante est utilisée pour "--[no]create-history-table":

CRÉER UNE TABLE SI NON EXISTE query_history (
somme de contrôle BIGINT UNSIGNED NOT NULL,
exemple TEXTE NON NULL,
ts_min DATEHEURE,
ts_max DATEHEURE,
ts_cnt FLOTTEUR,
Query_time_sum FLOAT,
Query_time_min FLOAT,
Query_time_max FLOAT,
Query_time_pct_95 FLOTTANT,
Query_time_stddev FLOAT,
Query_time_median FLOAT,
Lock_time_sum FLOAT,
Lock_time_min FLOTTANT,
Lock_time_max FLOTTANT,
Lock_time_pct_95 FLOTTANT,
Lock_time_stddev FLOTTANT,
Lock_time_median FLOAT,
Lignes_sent_sum FLOAT,
Rows_sent_min FLOTTANT,
Rows_sent_max FLOTTANT,
Rows_sent_pct_95 FLOTTANT,
Rows_sent_stddev FLOTTANT,
Lignes_sent_median FLOAT,
Rows_examined_sum FLOAT,
Rows_examined_min FLOTTANT,
Rows_examined_max FLOAT,
Rows_examined_pct_95 FLOTTANT,
Rows_examined_stddev FLOTTANT,
Lignes_examined_median FLOAT,
-- Attributs de slowlog étendus de Percona
-- http://www.percona.com/docs/wiki/patches:slow_extended
Rows_affected_sum FLOAT,
Rows_affected_min FLOAT,
Rows_affected_max FLOAT,
Rows_affected_pct_95 FLOTTANT,
FLOAT Rows_affected_stddev,
Lignes_affected_median FLOAT,
Lignes_read_sum FLOAT,
Rows_read_min FLOTTANT,
Rows_read_max FLOTTANT,
Lignes_read_pct_95 FLOAT,
Rows_read_stddev FLOTTANT,
Lignes_read_median FLOAT,
Merge_passes_sum FLOAT,
Merge_passes_min FLOTTANT,
Merge_passes_max FLOTTANT,
Merge_passes_pct_95 FLOTTANT,
Merge_passes_stddev FLOTTANT,
Merge_passes_median FLOAT,
InnoDB_IO_r_ops_min FLOTTANT,
InnoDB_IO_r_ops_max FLOTTANT,
InnoDB_IO_r_ops_pct_95 FLOTTANT,
FLOTTEUR InnoDB_IO_r_ops_stddev,
InnoDB_IO_r_ops_median FLOAT,
InnoDB_IO_r_bytes_min FLOTTANT,
InnoDB_IO_r_bytes_max FLOTTANT,
InnoDB_IO_r_bytes_pct_95 FLOTTANT,
FLOAT InnoDB_IO_r_bytes_stddev,
InnoDB_IO_r_bytes_median FLOAT,
InnoDB_IO_r_wait_min FLOTTANT,
InnoDB_IO_r_wait_max FLOTTANT,
InnoDB_IO_r_wait_pct_95 FLOTTANT,
FLOTTEUR InnoDB_IO_r_wait_stddev,
InnoDB_IO_r_wait_median FLOAT,
InnoDB_rec_lock_wait_min FLOTTANT,
InnoDB_rec_lock_wait_max FLOAT,
InnoDB_rec_lock_wait_pct_95 FLOTTANT,
FLOTTEUR InnoDB_rec_lock_wait_stddev,
FLOTTEUR InnoDB_rec_lock_wait_median,
InnoDB_queue_wait_min FLOAT,
InnoDB_queue_wait_max FLOAT,
InnoDB_queue_wait_pct_95 FLOTTANT,
FLOTTEUR InnoDB_queue_wait_stddev,
InnoDB_queue_wait_median FLOAT,
InnoDB_pages_distinct_min FLOAT,
InnoDB_pages_distinct_max FLOAT,
InnoDB_pages_distinct_pct_95 FLOTTANT,
FLOTTEUR InnoDB_pages_distinct_stddev,
FLOTTEUR InnoDB_pages_distinct_median,
-- Attributs booléens (Oui/Non). Seuls le cnt et la somme sont nécessaires
-- pour ces. cnt est le nombre de fois où l'attribut a été enregistré,
-- et la somme est le nombre de fois où la valeur était Oui. Alors
-- sum/cnt * 100 est égal au pourcentage de fois enregistré qui
-- la valeur était Oui.
QC_Hit_cnt FLOTTANT,
QC_Hit_sum FLOAT,
Full_scan_cnt FLOTTANT,
Full_scan_sum FLOAT,
Full_join_cnt FLOTTANT,
Full_join_sum FLOAT,
Tmp_table_cnt FLOTTANT,
Tmp_table_sum FLOTTANT,
Tmp_table_on_disk_cnt FLOTTANT,
Tmp_table_on_disk_sum FLOTTANT,
Filesort_cnt FLOTTANT,
Filesort_sum FLOAT,
Filesort_on_disk_cnt FLOAT,
Filesort_on_disk_sum FLOAT,
CLÉ PRIMAIRE (somme de contrôle, ts_min, ts_max)
);

Notez que nous stockons le nombre (cnt) pour l'attribut ts uniquement ; il sera redondant pour
stockez-le pour d'autres attributs.

--hôte
forme courte : -h ; type : chaîne

Connectez-vous à l'hôte.

--ignore-attributs
type : tableau ; par défaut : arg, cmd, insert_id, ip, port, Thread_id, timestamp, exptime,
drapeaux, clé, res, val, server_id, offset, end_log_pos, Xid

N'agrégez pas ces attributs. Certains attributs ne sont pas des métriques de requête mais des métadonnées
qui n'a pas besoin d'être (ou ne peut pas être) agrégé.

--inherit-attributs
type : tableau ; par défaut : db,ts

S'ils sont manquants, héritez de ces attributs du dernier événement qui les avait.

Cette option définit quels attributs sont hérités ou reportés sur des événements qui ne
pas les avoir. Par exemple, si un événement a l'attribut db égal à "foo", mais que le
l'événement suivant n'a pas l'attribut db, alors il hérite de "foo" pour son attribut db.

--intervalle
type : flotteur ; par défaut : .1

Fréquence d'interrogation de la liste de processus, en secondes.

--itérations
tapez : entier ; par défaut : 1

Combien de fois itérer à travers le cycle de collecte et de rapport. Si 0, itérer jusqu'à
infini. Chaque itération s'exécute pendant un laps de temps "--run-time". Une itération est
généralement déterminé par une quantité de temps et un rapport est imprimé lorsque cette quantité de
le temps s'écoule. Avec "--run-time-mode" "interval", un intervalle est à la place déterminé par
l'intervalle de temps que vous spécifiez avec "--run-time". Voir "--run-time" et
"--run-time-mode" pour plus d'informations.

--limite
type : tableau ; par défaut : 95 % : 20

Limitez la sortie au pourcentage ou au nombre donné.

Si l'argument est un entier, signalez uniquement les N premières requêtes les plus mauvaises. Si l'argument
est un entier suivi du signe "%", indiquez ce pourcentage des pires requêtes.
Si le pourcentage est suivi de deux points et d'un autre entier, indiquez le premier
pourcentage ou le nombre spécifié par cet entier, selon la première éventualité.

La valeur est en fait un tableau de valeurs séparées par des virgules, une pour chaque élément dans
"--par groupe". Si vous ne spécifiez de valeur pour aucun de ces éléments, la valeur par défaut est la
meilleurs 95%.

Voir aussi "--outliers".

--Journal
type : chaîne

Imprimez toutes les sorties dans ce fichier une fois démonisé.

--commandé par
type : tableau ; par défaut : Query_time:sum

Triez les événements par cet attribut et cette fonction d'agrégation.

Il s'agit d'une liste d'expressions séparées par des virgules, une pour chaque "--group-by"
attribut. La valeur par défaut "Query_time:sum" est utilisée pour les attributs "--group-by" sans
des attributs "--order-by" explicitement donnés (c'est-à-dire, si vous spécifiez plus "--group-by"
attributs que les attributs "--order-by" correspondants). La syntaxe est
« attribut : agrégat ». Voir "ATTRIBUTS" pour les attributs valides. Les agrégats valides sont :

Signification globale
========= =============================
somme Somme/total valeur de l'attribut
min Valeur d'attribut minimale
max Valeur d'attribut maximale
cnt Fréquence/nombre de la requête

Par exemple, la valeur par défaut "Query_time:sum" signifie que les requêtes dans l'analyse de requête
rapport sera trié (trié) en fonction de la durée totale d'exécution de la requête ("Durée d'exécution").
"Query_time:max" classe les requêtes en fonction de leur temps d'exécution maximal, de sorte que le
requête avec le plus grand "Query_time" sera la liste en premier. "cnt" se réfère plus à
la fréquence de la requête dans son ensemble, sa fréquence d'apparition ; "Compter" est son
ligne correspondante dans le rapport d'analyse de la requête. Donc, tout attribut et "cnt" devraient
produisent le même rapport dans lequel les requêtes sont triées en fonction du nombre de fois où elles apparaissent.

Lors de l'analyse des journaux généraux ("--type" "genlog"), la valeur par défaut "--order-by" devient
"Query_time:cnt". Les journaux généraux ne signalent pas les heures de requête, donc seul l'agrégat "cnt"
est logique car tous les temps de requête sont nuls.

Si vous spécifiez un attribut qui n'existe pas dans les événements, alors pt-query-digest
revient à la valeur par défaut "Query_time:sum" et imprime un avis au début de la
rapport pour chaque classe de requête. Vous pouvez créer des attributs avec "--filter" et trier par
eux; voir "ATTRIBUTS" pour un exemple.

--valeurs aberrantes
type : tableau ; par défaut : Query_time:1:10

Signalez les valeurs aberrantes par attribut : centile : nombre.

La syntaxe de cette option est une liste de chaînes séparées par des virgules. le
le premier champ est l'attribut par lequel une valeur aberrante est définie. Le deuxième est un nombre
qui est comparé au 95e centile de l'attribut. Le troisième est facultatif et est
par rapport à l'agrégat cnt de l'attribut. Les requêtes qui passent cette spécification sont
ajouté au rapport, quelles que soient les limites que vous avez spécifiées dans "--limit".

Par exemple, pour signaler les requêtes dont le 95e centile Query_time est d'au moins 60 secondes
et qui sont vues au moins 5 fois, utilisez l'argument suivant :

--outliers Query_time:60:5

Vous pouvez spécifier une option --outliers pour chaque valeur dans "--group-by".

--output
type : chaîne ; par défaut : rapport

Comment formater et imprimer les résultats de l'analyse des requêtes. Les valeurs acceptées sont :

FORMAT DE VALEUR
======= ===============================
rapport Rapport d'analyse de requête standard
slowlog journal lent MySQL
json JSON, sur tableau par classe de requête
json-anon JSON sans exemples de requêtes

L'ensemble de la sortie "report" peut être désactivé en spécifiant "--no-report" (voir
"--[no]report"), et ses sections peuvent être désactivées ou réorganisées en spécifiant
"--format-rapport".

La sortie "json" a été introduite dans 2.2.1 et est toujours en développement, donc les données
la structure peut changer dans les versions futures.

--le mot de passe
forme courte : -p ; type : chaîne

Mot de passe à utiliser lors de la connexion. Si le mot de passe contient des virgules, elles doivent être échappées
avec une barre oblique inverse : "exam\,ple"

--pid
type : chaîne

Créez le fichier PID donné. L'outil ne démarre pas si le fichier PID existe déjà et
le PID qu'il contient est différent du PID actuel. Cependant, si le fichier PID
existe et que le PID qu'il contient n'est plus en cours d'exécution, l'outil écrasera le PID
fichier avec le PID actuel. Le fichier PID est supprimé automatiquement à la fermeture de l'outil.

--Port
forme courte : -P ; tapez : entier

Numéro de port à utiliser pour la connexion.

--liste des processus
tapez : DSN

Interrogez la liste de processus de ce DSN pour les requêtes, avec "--interval" sleep entre les deux.

Si la connexion échoue, pt-query-digest essaie de la rouvrir une fois par seconde.

--le progrès
type : tableau ; par défaut : heure,30

Imprimez les rapports d'avancement sur STDERR. La valeur est une liste séparée par des virgules en deux parties.
La première partie peut être un pourcentage, un temps ou des itérations ; la deuxième partie précise comment
souvent, une mise à jour doit être imprimée, en pourcentage, en secondes ou en nombre d'itérations.

--read-timeout
type : heure ; par défaut : 0

Attendez aussi longtemps pour un événement de l'entrée ; 0 pour attendre indéfiniment.

Cette option définit le temps maximum d'attente d'un événement à partir de l'entrée. Il s'applique à
tous les types d'entrée sauf "--processlist". Si un événement n'est pas reçu après la
l'heure spécifiée, le script arrête de lire l'entrée et imprime ses rapports. Si
"--iterations" est 0 ou supérieur à 1, la prochaine itération commencera, sinon le script
va sortir.

Cette option nécessite le module Perl POSIX.

--[pas] de rapport
par défaut : oui

Imprimez des rapports d'analyse de requête pour chaque attribut "--group-by". C'est la norme
fonctionnalité d'analyse du journal lent. Voir "SORTIE" pour la description de ce que cela fait
et à quoi ressemblent les résultats.

Si vous n'avez pas besoin d'un rapport (par exemple, lorsque vous utilisez "--review" ou "--history"), il est
il est préférable de spécifier "--no-report" car cela permet à l'outil de sauter certains coûteux
fonctionnement sans maintenance

--rapport-tout
Signalez toutes les requêtes, même celles qui ont été examinées. Cela n'affecte que le "rapport"
"--output" lors de l'utilisation de "--review". Sinon, toutes les requêtes sont toujours imprimées.

--format-rapport
type : tableau ; par défaut : rusage,date,hostname,files,header,profile,query_report,prepared

Imprimez ces sections du rapport d'analyse de requête.

IMPRESSIONS DE SECTIONS
============ ====================================== =================
rusage Temps CPU et utilisation de la mémoire signalés par ps
date Date et heure locales actuelles
hostname Nom d'hôte de la machine sur laquelle pt-query-digest a été exécuté
fichiers Fichiers d'entrée lus/parsés
header Résumé de l'ensemble du cycle d'analyse
profile Table de requêtes compacte pour une vue d'ensemble du rapport
query_report Informations détaillées sur chaque requête unique
préparé Déclarations préparées

Les sections sont imprimées dans l'ordre spécifié. Le rusage, la date, les fichiers et l'en-tête
les sections sont regroupées si elles sont spécifiées ensemble ; les autres sections sont séparées par
lignes vierges.

Voir "SORTIE" pour plus d'informations sur les différentes parties du rapport de requête.

--report-histogramme
type : chaîne ; par défaut : Query_time

Tracez la distribution des valeurs de cet attribut.

Le graphique de distribution est limité aux attributs basés sur le temps, donc le graphique
"Rows_examined", par exemple, produira un graphique inutile. Les graphiques ressemblent à :

# Distribution de l'heure de la requête
# 1nous
# 10nous
# 100nous
# 1 ms
# 10ms ############################
# 100ms ################################################ ########
# 1s ########
# 10s+

Voir "SORTIE" pour plus d'informations.

--reprendre
type : chaîne

Si spécifié, l'outil écrit le dernier décalage de fichier, s'il y en a un, dans le
nom de fichier. Lorsqu'il est exécuté à nouveau avec la même valeur pour cette option, l'outil lit le dernier
décalage du fichier par rapport au fichier, recherche cette position dans le journal et reprend l'analyse
événements à partir de ce moment-là.

--revoir
tapez : DSN

Enregistrez les classes de requêtes pour une révision ultérieure et ne signalez pas les classes déjà révisées.

La table par défaut est "percona_schema.query_review". Spécifiez la base de données (D) et la table
(t) Options DSN pour remplacer la valeur par défaut. La base de données et la table sont automatiquement
créé à moins que "--no-create-review-table" ne soit spécifié (voir
"--[no]create-review-table").

Si la table a été créée manuellement, elle doit avoir au moins les colonnes suivantes. Vous
pouvez ajouter plus de colonnes à vos propres fins, mais elles ne seront pas utilisées par pt-
requête-digest.

CRÉER UNE TABLE SI NON EXISTE query_review (
somme de contrôle BIGINT UNSIGNED NOT NULL PRIMARY KEY,
TEXTE d'empreinte digitale NON NULL,
exemple TEXTE NON NULL,
premier_vu DATETIME,
dernier_vu DATETIME,
revu par VARCHAR(20),
examiné_le DATETIME,
commentaires TEXTE
)

Les colonnes sont :

COLONNE SIGNIFICATION
=========== ======================================= =============
somme de contrôle Somme de contrôle 64 bits de l'empreinte de la requête
Empreinte digitale La version abstraite de la requête ; sa clé primaire
sample Le texte de requête d'un échantillon de la classe de requêtes
first_seen Le plus petit horodatage de cette classe de requêtes
last_seen Le plus grand horodatage de cette classe de requêtes
review_by Initialement NULL ; si défini, la requête est ignorée par la suite
review_on Initialement NULL ; n'a pas de signification particulière
commentaires Initialement NULL ; n'a pas de signification particulière

Notez que la colonne "fingerprint" est la véritable clé primaire pour une classe de requêtes.
La « somme de contrôle » n'est qu'un hachage cryptographique de cette valeur, qui fournit un
valeur qui est très probablement aussi unique.

Après l'analyse et l'agrégation des événements, votre table doit contenir une ligne pour chaque
empreinte digitale. Cette option dépend de "--group-by fingerprint" (qui est la valeur par défaut).
Cela ne fonctionnera pas autrement.

--Durée
type : heure

Combien de temps d'exécution pour chaque "--itérations". La valeur par défaut est de s'exécuter pour toujours (vous pouvez
interrompre avec CTRL-C). Parce que "--iterations" est défini par défaut sur 1, si vous spécifiez uniquement
"--run-time", pt-query-digest s'exécute pendant ce laps de temps, puis se ferme. Les deux
les options sont spécifiées ensemble pour effectuer des cycles de collecte et de rapport. Par example,
en spécifiant "--iterations" 4 "--run-time" "15m" avec une entrée continue (comme STDIN ou
"--processlist") entraînera l'exécution de pt-query-digest pendant 1 heure (15 minutes x 4),
rapport quatre fois, une fois à chaque intervalle de 15 minutes.

--mode-d'exécution
type : chaîne ; par défaut : horloge

Définissez sur quoi la valeur de "--run-time" opère. Voici les valeurs possibles pour
cette option:

horloge
"--run-time" spécifie une durée d'horloge réelle pendant laquelle l'outil doit
exécuté pour chaque "--itérations".

event
"--run-time" spécifie une durée de journalisation. Le temps d'enregistrement est déterminé par
horodatages dans le journal. Le premier horodatage vu est mémorisé, et chaque horodatage
après cela, il est comparé au premier pour déterminer combien de temps de journal s'est écoulé.
Par exemple, si le premier horodatage affiché est "12:00:00" et le suivant est "12:01:30",
c'est-à-dire 1 minute et 30 secondes de temps d'enregistrement. L'outil lira les événements jusqu'à ce que le
l'heure du journal est supérieure ou égale à la valeur "--run-time" spécifiée.

Étant donné que les horodatages dans les journaux ne sont pas toujours imprimés, ou pas toujours fréquemment imprimés,
ce mode varie en précision.

intervalle
"--run-time" spécifie les limites d'intervalle de temps de journal dans lesquelles les événements sont
divisés et des rapports sont générés. Ce mode est différent des autres car
il ne précise pas combien de temps exécuter. La valeur de "--run-time" doit être un intervalle
qui se divise également en minutes, heures ou jours. Par exemple, « 5 m » se divise uniformément
en heures (60/5=12, donc 12 intervalles de 5 minutes par heure) mais "7m" ne signifie pas
(60/7 = 8.6).

Spécifier "--run-time-mode interval --run-time 30m --iterations 0" est similaire à
en spécifiant "--run-time-mode clock --run-time 30m --iterations 0". Dans ce dernier
cas, pt-query-digest s'exécutera pour toujours, produisant des rapports toutes les 30 minutes, mais
cela ne fonctionne efficacement qu'avec des entrées continues comme STDIN et le
liste des processus. Pour les entrées fixes, comme les fichiers journaux, le premier exemple produit
plusieurs rapports en divisant le journal en intervalles de 30 minutes en fonction de
horodatages.

Les intervalles sont calculés à partir de la zéro seconde/minute/heure au cours de laquelle un horodatage
se produit, pas à partir de n'importe quel moment spécifié. Par exemple, avec 30 minutes
intervalles et un horodatage de "12:10:30", l'intervalle est pas "12:10:30" à
"12:40:30", il est "12:00:00" à "12:29:59". Ou, avec des intervalles d'une heure, c'est
"12:00:00" à "12:59:59". Lorsqu'un nouvel horodatage dépasse l'intervalle, un rapport est
imprimé et l'intervalle suivant est recalculé en fonction du nouvel horodatage.

Étant donné que "--iterations" vaut 1 par défaut, vous voudrez probablement spécifier une nouvelle valeur
sinon pt-query-digest n'obtiendra et ne rapportera que le premier intervalle du journal
puisque 1 intervalle = 1 itération. Si vous souhaitez obtenir et signaler chaque intervalle dans un
log, spécifiez "--iterations" 0.

--échantillon
tapez : entier

Filtrez toutes les occurrences sauf les N premières de chaque requête. Les requêtes sont filtrées sur
la première valeur dans "--group-by", donc par défaut, cela filtrera par empreinte digitale de requête.
Par exemple, "--sample 2" autorisera deux exemples de requêtes pour chaque empreinte digitale. Utile
en conjonction avec "--output slowlog" pour imprimer les requêtes. Vous voulez probablement définir
"--no-report" pour éviter les frais généraux d'agrégation et de rapport si vous utilisez simplement
ceci pour imprimer des exemples de requêtes. Un exemple complet :

pt-query-digest --sample 2 --no-report --output slowlog slow.log

--set-vars
type : tableau

Définissez les variables MySQL dans cette liste de paires "variable=valeur" séparées par des virgules.

Par défaut, l'outil définit :

wait_timeout=10000

Les variables spécifiées sur la ligne de commande remplacent ces valeurs par défaut. Par exemple,
spécifier "--set-vars wait_timeout=500" remplace la valeur par défaut de 10000.

L'outil imprime un avertissement et continue si une variable ne peut pas être définie.

--Afficher tout
type : hachage

Afficher toutes les valeurs de ces attributs.

Par défaut, pt-query-digest n'affiche que la valeur d'un attribut qui correspond à un
une seule ligne. Cette option vous permet de spécifier des attributs pour lesquels toutes les valeurs seront
être affiché (la largeur de ligne est ignorée). Cela ne fonctionne que pour les attributs avec des valeurs de chaîne
comme l'utilisateur, l'hôte, la base de données, etc. Plusieurs attributs peuvent être spécifiés, séparés par des virgules.

--puisque
type : chaîne

Analyser uniquement les requêtes plus récentes que cette valeur (analyse des requêtes depuis cette date).

Cette option vous permet d'ignorer les requêtes antérieures à une certaine valeur et d'analyser uniquement
les requêtes qui sont plus récentes que la valeur. La valeur peut être de plusieurs types :

* Valeur de temps simple N avec suffixe facultatif : N[shmd], où
s=secondes, h=heures, m=minutes, d=jours (par défaut s si aucun suffixe
donné); c'est comme dire "depuis N[shmd] il y a"
* Date complète avec option heures:minutes:secondes :
AAAA-MM-JJ [HH:MM::SS]
* Date courte de style MySQL :
AAMMJJ [HH:MM:SS]
* Toute expression de temps évaluée par MySQL :
CURRENT_DATE - INTERVALLE 7 JOURS

Si vous donnez une expression de temps MySQL et que vous n'avez pas également spécifié de DSN pour
"--explain", "--processlist" ou "--review", alors vous devez spécifier un DSN sur le
ligne de commande pour que pt-query-digest puisse se connecter à MySQL pour évaluer l'expression.

L'expression de temps MySQL est enveloppée dans une requête comme "SELECT
UNIX_TIMESTAMP( )", alors assurez-vous que l'expression est valide à l'intérieur de ce
requete. Par exemple, n'utilisez pas UNIX_TIMESTAMP() car
UNIX_TIMESTAMP(UNIX_TIMESTAMP()) renvoie 0.

Les événements sont supposés être chronologiques : événements plus anciens au début du journal
et des événements plus récents à la fin du journal. "--since" est strict : il ignore toutes les requêtes
jusqu'à ce qu'on en trouve un assez nouveau. Par conséquent, si les événements de requête ne sont pas
systématiquement horodatées, certaines peuvent être ignorées qui sont en fait assez nouvelles.

Voir aussi "--until".

--prise
formes courtes; type : chaîne

Fichier socket à utiliser pour la connexion.

--chronologie
Afficher une chronologie des événements.

Cette option permet à pt-query-digest d'imprimer un autre type de rapport : une chronologie des
événements. Chaque requête est toujours regroupée et agrégée en classes selon
"--group-by", mais ils sont ensuite imprimés dans l'ordre chronologique. Le rapport chronologique
imprime l'horodatage, l'intervalle, le nombre et la valeur de chaque classe.

Si tout ce que vous voulez est le rapport chronologique, spécifiez "--no-report" pour supprimer le
rapport d'analyse de requête par défaut. Sinon, le rapport chronologique sera imprimé au
fin avant le profil de temps de réponse (voir "--report-format" et "OUTPUT").

Par exemple, ceci:

pt-query-digest /chemin/vers/log --group-by distill --timeline

affichera quelque chose comme :

# ################################################## #######
# distiller rapport
# ################################################## #######
# 2009-07-25 11:19:27 1+00:00:01 2 SÉLECTIONNER foo
# 2009-07-27 11:19:30 00:01 2 SÉLECTIONNER la barre
# 2009-07-27 11:30:00 1+06:30:00 2 SÉLECTIONNER foo

--taper
type : tableau ; par défaut : slowlog

Le type d'entrée à analyser. Les types autorisés sont

journal binaire
Analysez un fichier journal binaire qui a d'abord été converti en texte à l'aide de mysqlbinlog.

Par exemple :

mysqlbinlog mysql-bin.000441 > mysql-bin.000441.txt

pt-query-digest --type binlog mysql-bin.000441.txt

journal général
Analysez un fichier journal général MySQL. Les logs généraux manquent de beaucoup d'"ATTRIBUTS", notamment
"Requête_heure". La valeur par défaut "--order-by" pour les journaux généraux devient
"Query_time:cnt".

ralenti
Analysez un fichier journal dans n'importe quelle variante du format de journal lent MySQL.

tcpdump
Inspecter les paquets réseau et décoder le protocole client MySQL, extraire les requêtes
et les réponses de celui-ci.

pt-query-digest ne surveille pas réellement le réseau (c'est-à-dire qu'il ne « renifle PAS
paquets"). Au lieu de cela, il analyse simplement la sortie de tcpdump. Vous êtes responsable
pour générer cette sortie ; pt-query-digest ne le fait pas pour vous. Ensuite tu envoies
ceci à pt-query-digest comme vous le feriez pour n'importe quel fichier journal : en tant que fichiers sur la ligne de commande ou
à STDIN.

L'analyseur s'attend à ce que l'entrée soit formatée avec les options suivantes : "-x -n -q
-tttt". Par exemple, si vous souhaitez capturer la sortie de votre machine locale, vous
peut faire quelque chose comme ce qui suit (le port doit arriver en dernier sur FreeBSD) :

tcpdump -s 65535 -x -nn -q -tttt -i tout -c 1000 port 3306 \
> mysql.tcp.txt
pt-query-digest --type tcpdump mysql.tcp.txt

Les autres paramètres de tcpdump, tels que -s, -c et -i, dépendent de vous. Juste faire
Assurez-vous que la sortie ressemble à ceci (il y a un saut de ligne dans la première ligne pour éviter
problèmes de page de manuel):

2009-04-12 09:50:16.804849 IP 127.0.0.1.42167
> 127.0.0.1.3306 : tcp 37
0x0000 : 4508 0059 6eb2 4000 4006 cde2 7f00 0001
0x0010 : ....

N'oubliez pas que tcpdump a une option -c pratique pour s'arrêter après avoir capturé un certain nombre de
paquets ! C'est très utile pour tester votre commande tcpdump. Notez que tcpdump
ne peut pas capturer le trafic sur un socket Unix. Lire
<http://bugs.mysql.com/bug.php?id=31577> si vous êtes confus à ce sujet.

Devananda Van Der Veen a expliqué sur le blog MySQL Performance comment capturer
trafic sans perdre de paquets sur des serveurs occupés. Les paquets abandonnés provoquent pt-query-
digest pour manquer la réponse à une demande, puis voir la réponse à une demande ultérieure
et attribuez le mauvais temps d'exécution à la requête. Vous pouvez changer le filtre en
quelque chose comme ce qui suit pour aider à capturer un sous-ensemble des requêtes. (Voir
<http://www.mysqlperformanceblog.com/?p=6092> pour plus de détails.)

tcpdump -i tout -s 65535 -x -n -q -tttt \
'port 3306 et tcp[1] & 7 == 2 et tcp[3] & 7 == 2'

Tous les serveurs MySQL exécutés sur le port 3306 sont automatiquement détectés dans le tcpdump
sortir. Par conséquent, si la sortie tcpdump contient des paquets de plusieurs serveurs sur
port 3306 (par exemple, 10.0.0.1:3306, 10.0.0.2:3306, etc.), tous les paquets/requêtes
de tous ces serveurs seront analysés ensemble comme s'il s'agissait d'un seul serveur.

Si vous analysez le trafic d'un serveur MySQL qui ne s'exécute pas sur le port 3306,
voir "--watch-server".

Notez également que pt-query-digest peut ne pas signaler la base de données pour les requêtes lorsque
l'analyse de la sortie tcpdump. La base de données n'est découverte que lors de la connexion initiale
événements pour un nouveau client ou lorsque est exécuté. Si la sortie tcpdump
ne contient aucun de ces éléments, alors pt-query-digest ne peut pas découvrir la base de données.

Les instructions préparées côté serveur sont prises en charge. Le trafic crypté SSL ne peut pas être
inspecté et décodé.

journal brut
Les logs bruts ne sont pas des logs MySQL mais de simples fichiers texte avec une instruction SQL par ligne,
comme:

SÉLECTIONNER c DE t O id=1
/* Bonjour le monde! */ SÉLECTIONNER * DEPUIS t2 LIMITE 1
INSÉRER DANS t (a, b) VALEURS ('foo', 'bar')
INSÉRER DANS t SELECT * FROM singes

Étant donné que les journaux bruts n'ont aucune métrique, de nombreuses options et fonctionnalités de pt-query-
digest ne fonctionne pas avec eux.

Un cas d'utilisation des journaux bruts consiste à classer les requêtes par nombre lorsque la seule information
disponible est une liste de requêtes, de l'interrogation "SHOW PROCESSLIST" par exemple.

--jusqu'à
type : chaîne

Analyser uniquement les requêtes antérieures à cette valeur (analyser les requêtes jusqu'à cette date).

Cette option vous permet d'ignorer les requêtes plus récentes qu'une certaine valeur et d'analyser uniquement
les requêtes qui sont plus anciennes que la valeur. La valeur peut être du même type
répertorié pour "--depuis".

Contrairement à "--since", "--until" n'est pas strict : toutes les requêtes sont analysées jusqu'à ce que l'on ait un
horodatage égal ou supérieur à "--until". Ensuite, toutes les requêtes suivantes sont
ignoré.

--utilisateur
forme courte : -u ; type : chaîne

Utilisateur pour la connexion si ce n'est pas l'utilisateur actuel.

--variantes
type : tableau

Indiquez le nombre de variations dans les valeurs de ces attributs.

Les variations montrent combien de valeurs distinctes un attribut avait dans une classe. L'habituel
la valeur de cette option est "arg" qui montre combien de requêtes distinctes étaient dans le
classer. Cela peut être utile pour déterminer la capacité de mise en cache d'une requête.

Les valeurs distinctes sont déterminées par les sommes de contrôle CRC32 des valeurs des attributs. Ces
les sommes de contrôle sont signalées dans le rapport de requête pour les attributs spécifiés par cette option,
comme:

# arg crc 109 (1/25%), 144 (1/25%)... 2 de plus

Dans cette classe, il y avait 4 requêtes distinctes. Les sommes de contrôle des deux premiers
les variations sont montrées, et chacune s'est produite une fois (ou, 25% du temps).

Le nombre de variations distinctes est approximatif car seulement 1,000 XNUMX variations sont
enregistré. Le mod (%) 1000 de la somme de contrôle CRC32 complète est enregistré, donc certains distincts
les sommes de contrôle sont traitées comme égales.

--version
Afficher la version et quitter.

--[no]vérification de la version
par défaut : oui

Recherchez la dernière version de Percona Toolkit, MySQL et d'autres programmes.

Il s'agit d'une fonctionnalité standard de « recherche automatique des mises à jour », avec deux
caractéristiques. Tout d'abord, l'outil vérifie la version des autres programmes sur le système local dans
en plus de sa propre version. Par exemple, il vérifie la version de chaque serveur MySQL
il se connecte à Perl et au module Perl DBD::mysql. Deuxièmement, il vérifie et avertit
sur les versions avec des problèmes connus. Par exemple, MySQL 5.5.25 avait un bogue critique et
a été réédité en tant que 5.5.25a.

Toutes les mises à jour ou problèmes connus sont imprimés sur STDOUT avant la sortie normale de l'outil.
Cette fonction ne doit jamais interférer avec le fonctionnement normal de l'outil.

Pour plus d'informations, visitez .

--watch-serveur
type : chaîne

Cette option indique à pt-query-digest l'adresse IP et le port du serveur (comme
"10.0.0.1:3306") à surveiller lors de l'analyse de tcpdump (pour "--type" tcpdump); tous les autres
les serveurs sont ignorés. Si vous ne le spécifiez pas, pt-query-digest surveille tous les serveurs en
à la recherche de n'importe quelle adresse IP utilisant le port 3306 ou "mysql". Si vous regardez un serveur
avec un port non standard, cela ne fonctionnera pas, vous devez donc spécifier l'adresse IP et le port
regarder.

Si vous voulez regarder un mélange de serveurs, certains fonctionnant sur le port standard 3306 et d'autres
fonctionnant sur des ports non standard, vous devez créer des sorties tcpdump distinctes pour le
serveurs de ports non standard, puis spécifiez cette option pour chacun. À l'heure actuelle pt-query-
digest ne peut pas détecter automatiquement les serveurs sur le port 3306 et être également invité à surveiller un serveur sur un
port non standard.

DSN OPTIONS

Ces options DSN sont utilisées pour créer un DSN. Chaque option est donnée comme "option=valeur".
Les options sont sensibles à la casse, donc P et p ne sont pas la même option. Il ne peut y avoir
espace avant ou après le "=" et si la valeur contient un espace, il doit être entre guillemets.
Les options DSN sont séparées par des virgules. Voir la page de manuel percona-toolkit pour plus de détails.

· UNE

dsn : jeu de caractères ; copie : oui

Jeu de caractères par défaut.

· RÉ

dsn : base de données ; copie : oui

Base de données par défaut à utiliser lors de la connexion à MySQL.

· F

dsn : mysql_read_default_file ; copie : oui

Lire uniquement les options par défaut du fichier donné.

· H

dsn : hôte ; copie : oui

Connectez-vous à l'hôte.

·p

dsn : mot de passe ; copie : oui

Mot de passe à utiliser lors de la connexion. Si le mot de passe contient des virgules, elles doivent être échappées
avec une barre oblique inverse : "exam\,ple"

P

dsn : port ; copie : oui

Numéro de port à utiliser pour la connexion.

·S

dsn : mysql_socket ; copie : oui

Fichier socket à utiliser pour la connexion.

t

La table "--review" ou "--history".

· vous

dsn : utilisateur ; copie : oui

Utilisateur pour la connexion si ce n'est pas l'utilisateur actuel.

ENVIRONNEMENT

La variable d'environnement "PTDEBUG" active la sortie de débogage détaillé vers STDERR. Autoriser
débogage et capture toutes les sorties dans un fichier, exécutez l'outil comme :

PTDEBUG=1 pt-query-digest ... > FILE 2>&1

Attention : la sortie de débogage est volumineuse et peut générer plusieurs mégaoctets de sortie.

SYSTÈME EXIGENCES

Vous avez besoin de Perl, DBI, DBD::mysql et de certains packages de base qui doivent être installés dans n'importe quel
raisonnablement nouvelle version de Perl.

Utilisez pt-query-digestp en ligne en utilisant les services onworks.net