![\"twitter\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/twitter.png\" "\\"Share")
<\/a><\/a>![\"linkedin\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/linkedin.png\" "\\"Share")
<\/a>![\"mail\"](\"https:\/\/blog.capdata.fr\/wp-content\/plugins\/social-media-feather\/synved-social\/image\/social\/regular\/48x48\/mail.png\" "\\"Share")
<\/a>![\"\"](\"https:\/\/blog.capdata.fr\/wp-content\/uploads\/2019\/08\/endofroad.png\")
<\/p>\n
Avant la version 5.6.24 ou 5.7.6 de MySQL, il n’y a aucun moyen de param\u00e9trer la taille maximale du texte SQL captur\u00e9 dans P_S.events_statements_summary_by_digest<\/i> et events_statements_(current,history,history_long)<\/i>. Il est fix\u00e9 \u00e0 1024 octets sans possibilit\u00e9 de le changer, et sur ces versions on peut parfois se retrouver frustr\u00e9 de ne pouvoir capturer qu’une partie seulement du texte SQL normalis\u00e9 ou complet pour pouvoir r\u00e9cup\u00e9rer le plan d’ex\u00e9cution :<\/p>\n Ici le DIGEST_TEXT aura \u00e9t\u00e9 anonymis\u00e9 volontairement, mais on voit qu’il est tronqu\u00e9 \u00e0 1013 octets et se termine par ‘…’<\/p>\n En effet, une fois de plus si l’on suit la documentation officielle <\/a>:<\/p>\n “(…) In MySQL 5.6.24 and 5.6.25, performance_schema_max_digest_length is not available and max_digest_length applies to all digest computation. Before MySQL 5.6.24, neither max_digest_length nor performance_schema_max_digest_length are available and a fixed maximum of 1024 bytes applies to all digest computation.”<\/i><\/p>\n Il faut donc migrer dans une version sup\u00e9rieure ou \u00e9gale \u00e0 5.6.24, 5.7.6 ou 8.0. Dans ces versions de nouveaux param\u00e8tres permettent de lever cette limitation:<\/p>\n – performance_schema_digests_size<\/i> \u00e9tait d\u00e9j\u00e0 pr\u00e9sente avant la 5.6.24 et 5.7.6, elle sert \u00e0 sp\u00e9cifier la taille maximale de la vue dynamique (le ‘consumer’ events_statements_summary_by_digest<\/i>) stockant les digests. Il est important de monitorer la taille de cette vue car une fois la limite atteinte, tous les nouveaux digests vont chasser les plus anciens<\/a> et ceux-ci seront perdus. Attention le param\u00e8tre est statique…<\/p>\n – performance_schema_max_digest_length<\/i> et max_digest_length<\/i> sont donc les deux petites nouveaut\u00e9s. max_digest_length<\/i> est la quantit\u00e9 de m\u00e9moire maximale que mysqld r\u00e9serve par session pour calculer une version ‘normalis\u00e9e’ d’une requ\u00eate, c’est \u00e0 dire sans la partie litt\u00e9rale (principalement les arguments). C’est donc une limite haute. performance_schema_max_digest_length<\/i> quand \u00e0 lui est la quantit\u00e9 maximale d’octets que performance_schema va stocker pour la colonne DIGEST_TEXT, dans une vue type events_statements_summary_by_digest<\/i>. Il arrive en 5.6.26 et 5.7.8, deux sauts de puce de version apr\u00e8s max_digest_length<\/i>.<\/p>\n Par d\u00e9faut les 2 param\u00e8tres sont fix\u00e9s \u00e0 1024 octets, il faut toujours essayer de les aligner l’un avec l’autre sinon il y aura des risques de texte tronqu\u00e9, lorsque le second es plus grand que le premier notamment. <\/p>\n Si on choisi d’augmenter ces valeurs, il faut faire attention \u00e0 deux facteurs : Mais \u00e7a veut dire aussi qu’en augmentant ces param\u00e8tres on am\u00e9liore la pertinence de ce que l’on \u00e9chantillonne : en effet, on r\u00e9duit ainsi les chances de se retrouver avec deux textes normalis\u00e9s pour la m\u00eame requ\u00eate, alors qu’en r\u00e9duisant le param\u00e8tre, on risque d’augmenter la duplicit\u00e9 de ces requ\u00eates fonctionnellement identiques et nous induire en erreur…<\/p>\n Pour illustrer simplement ce concept, dans cet exemple on part du principe que notre taille de digest maximale sera de 32 octets, et on calcule un digest via la fonction md5()<\/a>:<\/p>\n On n’a qu’une seule signature alors que les 2 requ\u00eates sont diff\u00e9rentes. P_S va cumuler des statistiques pour 2 requ\u00eates diff\u00e9rentes, ce qui n’est pas l’id\u00e9al. Si j’augmente notre ‘faux’ param\u00e8tre de 32 \u00e0 64, j’obtiens bien deux signatures distinctes :<\/p>\n Conclusion si vous utilisez les vues de P_S et notamment events_statements_summary_by_digest<\/i>, pensez \u00e0 v\u00e9rifier ces param\u00e8tres ainsi que votre version de MySQL. Si vous \u00eates en dessous de la version 5.6.24 et 5.7.6, pensez \u00e0 migrer vers les derni\u00e8res versions mineures ou vers une version majeure sup\u00e9rieure. <\/p>\n A+. ~David. <\/p>\n Avant la version 5.6.24 ou 5.7.6 de MySQL, il n’y a aucun moyen de param\u00e9trer la taille maximale du texte SQL captur\u00e9 dans P_S.events_statements_summary_by_digest et events_statements_(current,history,history_long). Il est fix\u00e9 \u00e0 1024 octets sans possibilit\u00e9 de le changer, et sur ces… Continuer la lecture \r\nmysql> select version(), DIGEST, DIGEST_TEXT, length(DIGEST_TEXT)\r\n -> from events_statements_summary_by_digest\r\n -> where DIGEST='34db15d11344f6c9896a852321c737ea' \\G\r\n*************************** 1. row ***************************\r\n version(): 5.6.17-1~dotdeb.1-log\r\n DIGEST: 34db15d11344f6c9896a852321c737ea\r\n DIGEST_TEXT: SELECT COUNT ( blankblankblank) AS blankblankblank FROM blankblankblank AS blankblankblank \r\nJOIN blankblankblank AS blankblankblank ON ( blankblankblank . blankblankblank = blankblankblank . blankblankblank ) \r\nJOIN blankblankblank AS blankblankblank ON ( blankblankblank . blankblankblank = blankblankblank . blankblankblank ) \r\nLEFT JOIN blankblankblank AS blankblankblank ON ( blankblankblank . blankblankblank = blankblankblank . blankblankblank \r\nAND blankblankblank . blankblankblank = ? AND blankblankblank . blankblankblank = ? AND blankblankblank . blankblankblank = ? \r\nAND blankblankblank . blankblankblank = ? ) JOIN blankblankblank AS blankblankblank ON ( blankblankblank . blankblankblank = ? ) \r\nLEFT JOIN blankblankblank AS blankblankblank ON ( blankblankblank . blankblankblank = blankblankblank . blankblankblank \r\nAND blankblankblank . blankblankblank = ? AND blankblankblank . blankblankblank = ? ) JOIN blankblankblank AS blankblankblank \r\nON ( blankblankblank . blankblankblank = ? ) LEFT JOIN blankblankblank AS blankblankblank \r\nON ( blankblankblank . blankblankblank = blankblankblank . blankblankblank AND blankblankblank . blankblankblank = ? \r\nAND blankblankblank . blankblankblank = ? ) JOIN blankblankblank AS blankblankblank \r\nON ( blankblankblank . blankblankblank = blankblankblank . blankblankblank ) JOIN ...\r\nlength(DIGEST_TEXT): 1013\r\n1 row in set (0,00 sec)\r\n<\/pre>\n
\r\nmysql> select version(), VARIABLE_NAME, VARIABLE_VALUE\r\n -> from performance_schema.global_variables\r\n -> where VARIABLE_NAME like '%digest%';\r\n+--------------+--------------------------------------+----------------+\r\n| version() | VARIABLE_NAME | VARIABLE_VALUE |\r\n+--------------+--------------------------------------+----------------+\r\n| 5.7.10-3-log | max_digest_length | 1024 |\r\n| 5.7.10-3-log | performance_schema_digests_size | 10000 |\r\n| 5.7.10-3-log | performance_schema_max_digest_length | 1024 |\r\n+--------------+--------------------------------------+----------------+\r\n3 rows in set (0.00 sec)\r\n<\/pre>\n
\n– Le nombre de connexions simultan\u00e9es: <\/b>ces 1024 octets sont allou\u00e9s \u00e0 chaque session, donc la charge m\u00e9moire de l’instance globale augmente avec les connexions.
\n– La versatilit\u00e9 du code: <\/b> plus il y a de types de requ\u00eates diff\u00e9rents fondamentalement les unes des autres, et plus le nombre de digests va augmenter, donc la saturation de la vue \u00e0 10000 lignes par d\u00e9faut risque d’arriver plus vite. <\/p>\n\r\nmysql> select md5(substring('SELECT COL1, COL2, COL3 FROM T1 WHERE COL1=?',1,32))\r\n -> UNION\r\n -> select md5 (substring('SELECT COL1, COL2, COL3 FROM T1 WHERE COL2=?',1,32)) ;\r\n+---------------------------------------------------------------------+\r\n| md5(substring('SELECT COL1, COL2, COL3 FROM T1 WHERE COL1=?',1,32)) |\r\n+---------------------------------------------------------------------+\r\n| c35bb84d1fe037fa656a026bdf3a7738 |\r\n+---------------------------------------------------------------------+\r\n1 row in set (0.00 sec)\r\n<\/pre>\n\r\nmysql> select md5(substring('SELECT COL1, COL2, COL3 FROM T1 WHERE COL1=?',1,64))\r\n -> UNION\r\n -> select md5(substring('SELECT COL1, COL2, COL3 FROM T1 WHERE COL2=?',1,64))\r\n -> ;\r\n+---------------------------------------------------------------------+\r\n| md5(substring('SELECT COL1, COL2, COL3 FROM T1 WHERE COL1=?',1,64)) |\r\n+---------------------------------------------------------------------+\r\n| cbed77bff188dd322f7a18e10d011b93 |\r\n| 239d970bb69a1f94216aecaa14252e63 |\r\n+---------------------------------------------------------------------+\r\n2 rows in set (0.00 sec)\r\n<\/pre>\n<\/a><\/a><\/a>","protected":false},"excerpt":{"rendered":"