Comment faire pour désactiver la mise en Cache de Requête MySQL

Je suis en train de faire quelque analyse comparative des différentes requêtes sur les différentes colonnes mais MySQL ne va pas me laisser faire. Après la première exécution d'une requête, je ne peux jamais obtenir le même temps d'exécution de cette requête à nouveau. Par exemple, si la requête s'exécute en 0.062 s la première fois, je ne peux jamais obtenir le même temps d'exécution pour les 2e, 3e, etc pistes. Il devient de 0 secondes ou quelque chose comme 0.015.

J'ai lu de nombreux messages sur la désactivation et la compensation de MySQL query cache, mais aucun d'eux n'a été d'aucune aide pour moi.

comme cela, AFIN de poster ici

Peu importe ce que je fais, MySQL semble insister sur l'utilisation des résultats mis en cache.

J'ai redémarrer le serveur MySQL Workbench puis-je exécuter;

set global query_cache_type=0;
set global query_cache_size=0;
flush query cache;
reset query cache;

Le temps d'exécution continue de s'afficher 0 secondes.

Seule variable de serveur que je n'ai pas été capable de changer est "have_query_cache". Sa valeur est "oui" et quand j'essaie de le régler sur "non" Workbench dit qu'il est en lecture seule.

Je fais aussi;

set profiling=1;
run my select query
show profile for query 2;

Profilage résultat montre ceci:

'starting', '0.000077'
'checking permissions', '0.000007'
'Opening tables', '0.000016'
'init', '0.000035'
'System lock', '0.000009'
'optimizing', '0.000013'
'statistics', '0.000094'
'preparing', '0.000008'
'executing', '0.000002'
'Sending data', '0.000016'
'end', '0.000002'
'query end', '0.000003'
'closing tables', '0.000005'
'freeing items', '0.000139'
'cleaning up', '0.000009'

Si je ne me trompe pas, cela montre qu'aucun caches sont utilisés droit? Mais je continue de voir les 0 secondes. pour le temps d'exécution.

Modifier: La question je suis en cours d'exécution est d'une requête de sélection à l'aide de "SQL_NO_CACHE" comme suit:

SELECT SQL_NO_CACHE col1,now() from mytable where col2="some_value"

(J'ai ajouté la fonction now() pour m'aider à prévenir la requête de mise en cache)

Edit2: j'utilise innoDB, MySQL 5.6.10

Quelqu'un pourrait-il m'aider car je ne peut pas voir ce qui se passe ici.

Merci beaucoup!

  • Est-il possible que, parfois, la requête s'exécute pour plus de 0 secondes si la charge de la base de données est élevé?
  • C'est hors-sujet et appartient à dba.stackexchange.com
  • Je ne comprends pas ce que tu veux dire mais il n'y a pas de charge sur la base de données maintenant. Je suis en train de faire ces tests sur mon développement local de la machine.
  • J'ai essayé d'exécuter ces 4 premières commandes dans votre post, après chaque requête..et il semble fonctionner. Les requêtes de prendre presque en même temps quand exécuter plusieurs fois successivement.
InformationsquelleAutor SoftwareTheory | 2013-04-16
  1. 10

    L'exécution de la requête pour la première fois fait InnoDB de pool de mémoire tampon remplir avec vos tables pertinente des blocs.

    Depuis de ré-exécuter la requête nécessite exactement les mêmes blocs, il évite la question de la nécessité de les lire à partir du disque quand il est re-run, le rendant nettement plus rapide.

    • Il serait donc beaucoup plus rapide que ce serait aller à partir de 0.062 secondes de 0! sec de 2 millions de lignes?
    • pourtant, il le ferait. Les disques sont très lents. Le chargement de données à partir de la mémoire est ridiculement plus rapide que de disque..
    • quand est-mysql pool de mémoire tampon invalidé? Je m'interroge sur l'incohérence lors de la récupération des résultats par l'utilisation de vieux blocs.
    • avec votre direction sur innoDB pool de mémoire tampon j'ai fait quelques recherches et partagé mes découvertes et les idées sur une réponse ci-dessous. Pouvez-vous confirmer cette réponse? Si oui, je crois que je dois marquer votre réponse acceptée et aussi donner quelques crédits à TheVedge.
    • jamais, il contient toujours des données valides.
    • mysql pool de mémoire tampon n'est pas invalidée, mais il est, vous pouvez dire "mis à jour et actualisé" considérant que certains innoDM paramètres. Pour plus d'info vous pouvez consulter ce lien: dev.mysql.com/doc/refman/4.1/en/innodb-buffer-pool.html

    InformationsquelleAutor Quassnoi
  2. 23

    Cela pourrait être dû au cache de données elle-même, et ne le cache de requêtes.

    Pour vous en assurer, vous pouvez désactiver la mise en cache de requêtes pour une seule instruction par l'ajout de SQL_NO_CACHE après votre SÉLECTIONNEZ déclaration.

    Ex:

    SELECT SQL_NO_CACHE field FROM table.

    • Je suis désolé de ne pas mentionner mon utilisation de SQL_NO_CACHE dans ma requête déjà. Édité à ma question.
    • Votre requête n'est pas en utilisant la mise en cache de requêtes à tous, alors. C'est soit à l'aide de la mémoire tampon de la piscine (si l'on utilise innodb) ou le cache du système d'exploitation (si vous utilisez myisam).
    • J'utilise innoDB. Je pense que même si c'est le pool de mémoire tampon (comme Quassnoi aussi mentionné ci-dessous), je ne devrais pas être prise en 0 secondes délai d'exécution de 2 millions de lignes de droit? Et est-il un moyen de désactiver/reset de pool de mémoire tampon pour vérifier cette possibilité?
    • Le seul moyen de purger le pool de mémoire tampon est de redémarrer l'instance MySQL.
    • merci Bill, je compris:)
    • Que le plat ne fonctionne pas (du moins pour ma connexion à une base de données MySQL. La seule façon pour moi d'obtenir des résultats précis est de "RECONNECTER" avant de réexécuter une requête.
    • La mise en cache de requêtes persistantes et les plus partagées sur les connexions. Si la reconnexion corrige ce qui ne va vous, alors vous avez un problème différent.

    InformationsquelleAutor ESG
  3. 7

    Vous pouvez vérifier la différence entre le pool de mémoire tampon de page lectures /page lit qui a dû aller sur le disque pour obtenir la page:

    mysql> SHOW SESSION STATUS LIKE 'Innodb_buffer_pool_read%';
mysql> ...run a query...
mysql> SHOW SESSION STATUS LIKE 'Innodb_buffer_pool_read%';

    Comparer ces valeurs à partir du rapport, et de remarquer à quel point ils grandissent:

    +---------------------------------------+----------+
| Variable_name                         | Value    |
+---------------------------------------+----------+
| Innodb_buffer_pool_read_requests      | 10327490 |
| Innodb_buffer_pool_reads              | 1133     |
+---------------------------------------+----------+

    La read_requests sont logiques lectures de page, qui peut lire dans les pages déjà dans le pool de mémoire tampon. Si ce nombre augmente après votre requête, mais lit de ne pas grandir, votre requête a obtenu son résultat uniquement à partir du pool de mémoire tampon.

    La lit sont le nombre de lectures de page qui a dû aller sur le disque et assumer le coût des I/O pour copier des pages dans le pool de mémoire tampon. Si ce nombre augmente après votre requête, puis il avait pour charger des données à partir du disque.

    Pour en savoir plus sur la différence entre la performance de l'accès à la mémoire contre les accès disque, lire http://everythingisdata.wordpress.com/2009/10/17/numbers-everyone-should-know/

    Re votre commentaire:

    L' "l'Ouverture de tables" est liée à une mémoire cache de tables InnoDB, un peu comme un dictionnaire de données. Les Tables sont ouvertes la première fois qu'ils sont référencés après un redémarrage. Une table donnée est entrée dans la mémoire de données du dictionnaire reste en mémoire indéfiniment, de sorte que l'utilisation de la mémoire peut pousser assez grand, si vous avez des milliers de tables. Dans MySQL 5.6, ils ont certains ne paramétrage des variables de mettre un bouchon sur l'utilisation de la mémoire, et l'expulsion de peu les tables utilisées. Mais ce mécanisme est séparé du pool de mémoire tampon qui stocke les pages de données et les index.

    Les "statistiques" est également séparé du pool de mémoire tampon. InnoDB maintient en mémoire des statistiques sur les données et les index, qui l'utilise pour guider l'optimiseur de requête. Les statistiques sont actualisées automatiquement lorsque vous accédez d'abord à une table InnoDB, lorsque vous exécutez AFFICHER la TABLE de STATUT ou de l'exécution de certaines requêtes contre la INFORMATION_SCHEMA, lorsque vous exécutez ANALYSER la TABLE, et aussi lorsque la taille de la table de change de manière significative. InnoDB génère ces statistiques de la lecture d'un nombre fixe de pages de la table au hasard, ce qui est susceptible de frapper le disque si vous avez un rhume de pool de mémoire tampon.

    • Le projet de loi, merci pour l'info je vais essayer ça dès que je peux (CMMI évaluation est prise de toute ma journée en ce moment). Que pensez-vous de ma propre réponse ci-dessus? Pensez-vous que je suis sur la bonne voie, je reçois le pool de mémoire tampon de droit? Voyez-vous des points que je suis mal dans cette réponse de la mienne? Merci beaucoup.
    • Alors, quelle est la façon d'arrêter ces InnoDB mise en mémoire tampon et la mise en cache?
    • Je ne suis pas sûr de savoir pourquoi vous posez cette question. Vous voulez mise en cache de l'open tables et index des statistiques, parce que l'alternative, c'est de lire à partir du disque à chaque fois que vous faites une requête.
    • Quand on fait des mesures, je tiens à le désactiver afin que nous puissions mesurer les pommes contre des pommes.
    • ah, a obtenu. Non, il n'y a pas moyen de purger le buffer pool manuellement. Vous devrez redémarrer mysqld avant l'exécution de vos tests.
    • Est net stop mysql suffisant? Ou avons-nous encore besoin de courir tout flushes et etc?
    • oui, net stop mysql arrête le service. Qui arrête le processus et les bouffées de chaleur le pool de mémoire tampon. Bien sûr, alors vous avez à net start mysql avant de vous peut faire le travail à nouveau. Aussi, si vous utilisez MySQL 5.6, vous devez vous assurer que vous n'êtes pas automatiquement re-charger les pages auparavant dans le pool de mémoire tampon au démarrage (voir dev.mysql.com/doc/refman/5.6/en/innodb-preload-buffer-pool.html).
    • Pourrait être une alternative à SELECT SQL_NO_CACHE ....... et il va traiter votre requête, comme si vous avez juste commencé et aller tout le chemin vers votre disque?
    • Pas de. SQL_NO_CACHE fait que le résultat de la requête ne sera pas lu à partir de la mise en cache de requêtes. Mais le InnoDB pool de mémoire tampon est un autre mécanisme de mise en cache. Le pool de mémoire tampon stocke InnoDB pages. La mise en cache de requêtes magasins de compléter les résultats de la requête. Ils sont utilisés pour des choses différentes. Il n'y a pas de requête option pour contourner la InnoDB pool de mémoire tampon.

    InformationsquelleAutor Bill Karwin
  4. 4

    OK. J'ai donc été diggin' sur ce innoDB pool de mémoire tampon d'émission. Merci @Quassnoi, @TheVedge pour la signaler. Il a été très utile pour le travail suivant.

    J'ai essayé de trouver un moyen de le désactiver ou de le réinitialiser innoDB pool de mémoire tampon, mais je n'ai pas été en mesure de trouver un moyen autre que de redémarrer le serveur MySQL. (Pour redémarrer le serveur sur une machine windows, vous pouvez utiliser les services.msc ou invite de commande.)

    Je suppose que toutes les variables de configuration des paramètres et l'utilisation de "SQL_NO_CACHE" était plus que suffisant pour éviter de cache à utiliser, et également de vérifier le profilage des résultats je n'ai pas été voir un cache de référence ni (vérifier le post original).

    Alors j'ai décidé de vérifier le profilage pour la même requête du 1er et 2ème court après le redémarrage du serveur MySQL. De cette façon, je serais en mesure de voir ce qui se passait au cours de l'exécution de la requête, étape par étape.

    1er courir après le redémarrage du serveur donné les étapes suivantes et horaires:

    'starting', '0.000078'
'checking permissions', '0.000005'
'Opening tables', '0.120329'
'init', '0.000107'
'System lock', '0.000012'
'optimizing', '0.000024'
'statistics', '0.065317'
'preparing', '0.000026'
'executing', '0.000003'
'Sending data', '0.000038'
'end', '0.000005'
'query end', '0.000006'
'closing tables', '0.000014'
'freeing items', '0.000463'
'cleaning up', '0.000039'

    Et ce sont les résultats de la 2e terme:

    'starting', '0.000068'
'checking permissions', '0.000006'
'Opening tables', '0.000019'
'init', '0.000046'
'System lock', '0.000007'
'optimizing', '0.000010'
'statistics', '0.000073'
'preparing', '0.000009'
'executing', '0.000002'
'Sending data', '0.000035'
'end', '0.000003'
'query end', '0.000003'
'closing tables', '0.000006'
'freeing items', '0.000181'
'cleaning up', '0.000015'

    Comme vous pouvez le voir il y a une énorme différence pour la durée de "l'ouverture de tables" et "statistiques" d'actions entre les deux exécutions et aucun des exécutions de référence à tous les caches.

    Les deux actions semblent être les plus longues de pièces pour la 1ère exécution (je crois qu'une partie de la création de innoDB pool de mémoire tampon), et une fois que la piscine est généré ces deux actions qui n'ont pas effectué comme fortement ainsi le beaucoup plus court temps d'exécution de la requête après le tampon de la création d'un pool.

    Lorsque vous résumer les temps d'exécution des différentes étapes pour la 2ème run-nous obtenir 0.000483 secondes et je pense que MySQL workbench montre ce résultat en 0.000 secondes qui pourrait aussi vous tromper à penser que la deuxième course a la suite de cache à l'aide, mais en fait il semble qu'il ne l'est pas. C'est juste un affichage de la question de précision pour l'exécution des durées de requêtes.

    Comme un résultat de ce que j'ai trouvé jusqu'à présent est en fait, j'ai été en mesure de désactiver l'utilisation des caches et c'est l'achèvement de innoDB pool de mémoire tampon qui accélère la deuxième requête tellement. Cela signifie aussi que je peux trouver un record de 2 millions de lignes dans 0.000483 secondes.

    Seriez-vous d'accord?

    InformationsquelleAutor SoftwareTheory
  5. 1

    Dans votre .ini/.cfg dans la section [mysqld], ajouter une ligne have_query_cache=0 # to prevent using resources from default of yes ccyy/mm/dd your initials. Avec vos autres changements, fermer/relancer MySQL. Vous ne devrait PAS observer de toute QC activité dans le profil de recherche.

    InformationsquelleAutor Wilson Hauck