7
votes

Y a-t-il un moyen d'obtenir des lignes_examine dans mysql sans le journal lent?

Je construis des informations de profil pour une application de culture à domicile. J'aimerais que la page de débogage affiche la requête envoyée avec combien de lignes ont été examinées sans supposer que Slow_log est allumé, laissez-le simplement l'analyser.

Retour en 2006, ce que je voulais était Pas possible < / a>. Est-ce toujours vrai aujourd'hui?

Je vois Peter Zaitsev a un Technique Où vous:

  1. Run Statut de flush;
  2. Exécutez la requête.
  3. Exécuter Afficher l'état comme "gestionnaire%";

    puis dans la sortie:

    handler_read_next = 42250 signifie 42250 lignes ont été analysées pendant cette analyse

    Ce qui ressemble à si MySQL n'examine que des index, il devrait vous donner le numéro. Mais y a-t-il un ensemble de Status Vars que vous pouvez sonder, additionner et découvrir combien de lignes examinées? Toute autre idée?


0 commentaires

4 Réponses :


1
votes

de Documentation :

handler_read_rnd

Nombre de demandes de lecture d'une ligne basée sur une position fixe. Cette valeur est élevée si vous faites beaucoup de questions nécessitant le tri du résultat. Vous avez probablement beaucoup de questions nécessitant MySQL de numériser des tables entières ou vous avez des jointures qui n'utilisent pas correctement les clés.

handler_read_rnd_next

Le nombre de demandes de lecture de la ligne suivante dans le fichier de données. Cette valeur est élevée si vous faites beaucoup de scans de table. Généralement, cela suggère que vos tables ne sont pas correctement indexées ou que vos requêtes ne sont pas écrites pour tirer parti des index que vous avez.

read_rnd * signifie lire des lignes de table réelles avec un FullScan.

Notez que cela ne montrera que s'il ya un scan d'index combiné avec une recherche de ligne, Il compte toujours comme clé clé.

pour le schéma comme celui-ci: xxx

, ces deux dernières requêtes retourneront tous les deux 1 Dans read_key , 101 in read_next et 0 dans les deux read_rnd et read_rnd_next , malgré le fait que les recherches de lignes réelles se produisent dans la deuxième requête.


0 commentaires

-2
votes

Préparez la requête avec expliquer. Dans MySQL qui affichera le chemin d'exécution de la requête, quelles tables ont été examinées ainsi que le nombre de lignes examinées pour chaque table.

Voici le Documentation .


3 commentaires

Expliquez est utile, mais cela ne vous dit pas combien de lignes ont été examinées.


Désolé, mais je dois être en désaccord sur expliquer. J'ai trouvé cela particulièrement utile lorsque vous essayez d'examiner les chemins d'exécution des requêtes qui impliquent des jointures. Il montrera le nombre de lignes examinées par table utilisées dans le chemin d'exécution. Je l'ai utilisé plusieurs fois pour résoudre les problèmes de jointure et des schémas indiciels.


Trouvez ou créez une table avec 1 million de lignes. Sélectionnez la limite distincte (champ) 10 ... mais assurez-vous que le champ est relativement mais pas complètement unique. Voyez combien de lignes il prétend avoir examiné. Étant donné que distinct est en interne comme le groupe, expliquez-vous que cela doit examiner toutes les lignes avant de retourner les uniques et cela vous dira qu'il a examiné un million de rangées. Mais il ne fera que regarder environ 10 rangées jusqu'à ce qu'il puisse satisfaire la limite. Si vous n'êtes toujours pas sûr de ne pas analyser les millions de lignes, retirez la limite et voyez combien de temps le disque dur se déroule avant même de commencer à cracher des résultats.



7
votes

C'est légèrement meilleur qu'en 2006. Vous pouvez émettre un statut de session show avant et après, puis examinez chacun des comptes de manutention_read_ * afin de pouvoir indiquer le nombre de lignes examinées.

Il n'y a vraiment pas d'autre moyen. Lorsque le protocole du serveur a un drapeau à dire si une balayage de table s'est produite, elle n'expose pas les rangées_examine. Même des outils tels que l'analyseur de requête de MySQL doivent fonctionner en exécutant le statut de session Show avant / après (bien que je pense que cela ne fonctionne que Statut de session après , car il se souvient des valeurs précédentes).

Je sais que ce n'est pas lié à votre question initiale, mais il y a d'autres composants coûteux auxquels se posent des rows_examiné. Si vous choisissez de le faire via le journal lent, vous devez consulter ce correctif:

http://www.percona.com/docs/wiki/ppatches : microslow_innodb # modifications_to_the_log_format

Je peux recommander à la recherche de "disk_tmp_table: oui" et "disk_fileort: oui".


2 commentaires

Merci Morgan. Alors, y a-t-il un algorithme garanti pour obtenir le nombre absolu droit des personnes handler_read_ * * Les sous-coutumes "magiques" sont dans votre déclaration (car évidemment, vous ne pouvez pas simplement les ajouter)? Je suis surpris de tous les grands blogs MySQL là-bas que personne n'a écrit la bonne façon de le faire.


Je ne suis pas sûr à 100% de ce que vous entendez par "garantit pour obtenir le nombre absolu droit de la manutention_read_ * colonnes". C'est vrai que Handler_read_ * peut être incrémenté plusieurs fois à plusieurs reprises en raison d'optimisations de sous-requises manquantes, mais dans mon esprit que vous voulez toujours voir cela compte vers le chiffre final, car ce n'est pas gratuit (bien que cela a probablement une chance plus élevée d'un coup de cache) . Ce que vous envisagez également de regarder quelque chose comme les statistiques qui sortent du statut de spectacle comme 'innodb_buffer_pool_read%'; (ou montrer le statut comme 'key_read%';) qui pourrait vous montrer des caches misses de cache.



3
votes

Démarrage de 5.6.3, la base de données MySQL Performance_Schema expose également des statistiques de relevés, dans des tables telles que Performance_Schema.events_statifs_Current.

Les statistiques collectées par des déclarations incluent la colonne "Rows_Examined".

voir http://dev.mysql.com/doc /refman/5.6/fr/events-statifs-Current-table.html

à partir de là, les statistiques sont agrégées pour fournir des résumés.

voir http://dev.mysql.com/doc/refman /5.6/fr/statement-summary-tables.html


0 commentaires