Cloud Web-old - Latence SQL suite MAJ sur Mysql 8.0
... / Latence SQL suite MAJ sur...
BMPCreated with Sketch.BMPZIPCreated with Sketch.ZIPXLSCreated with Sketch.XLSTXTCreated with Sketch.TXTPPTCreated with Sketch.PPTPNGCreated with Sketch.PNGPDFCreated with Sketch.PDFJPGCreated with Sketch.JPGGIFCreated with Sketch.GIFDOCCreated with Sketch.DOC Error Created with Sketch.
Frage

Latence SQL suite MAJ sur Mysql 8.0

Von
Pierre-ArnaudB
Erstellungsdatum 2024-09-30 15:59:40 (edited on 2024-11-18 11:03:27) in Cloud Web-old


Bonjour à toutes et à tous,
Je suis sur Mutu / Performance 4, depuis la Mise à jour sur Mysql 8.0 le service est devenu extrêmement lent sur les requêtes SQL. J'ai fouillé un peu pour voir de quoi cela pouvais provenir, mais sans trop de résultat, beaucoup de personne parle du cache qui est modifié sur mysql 8.0 mais sur un Mutu ovh je n'est pas accès à la configuration, Il y à t-il d'autres personnes je suppose dans mon cas ? Merci de vos réponses.


6 Antworten ( Latest reply on 2024-11-18 11:03:57 Von
janus57
)

Bonjour,


beaucoup de personne parle du cache qui est modifié sur mysql 8.0

le query cache a été supprimé par oracle dans mysql8 (Cf : https://dev.mysql.com/blog-archive/mysql-8-0-retiring-support-for-the-query-cache/).

Avec les modifications faite dans MySQL8 cela va avoir tendance a mettre en avant les problèmes de conception de site (genre pas assez d'index ou des query mal optimisé), du moins c'est comme ça que je le vois.

Note : cela existe toujours en MariaDB, et je comprend que certains hébergeurs est délaissé MySQL au profit de MariaDB (outre le fait que presque toutes les distributions ont fait de même par défaut)

Cordialement, janus57

Bonjour,
Effectivement, il faut voir coté optimisation des requêtes.
- Les tables sont elles lourdes ? (environ combien de lignes)
- Sont elles bien indexées ?

Merci Janus57 ainsi que CHORINP pour ta réponse, en effet tu renforces mes soupesons, pour le cache et pour l'amélioration des requêtes par contre en faisant un simple select pour lister 1500 entrées cela prend 7 à 8 sec maintenant avant 1 sec. donc on multiplie par 7 quasiment, voila la requête

$Query = "SELECT id, url_page FROM page_site_map";
$mysql_result = mysqli_query($link, $Query);
while($row = mysqli_fetch_array($mysql_result))
{
$id_page = $row['id'];
$url_page = $row['url_page'];
}

Il faudrait voir le contexte...


$Query = "SELECT id, url_page FROM page_site_map";

Une boucle qui lit tous les enregistrements et gourmand en ressources a mon sens, Y a t il vraiment besoins d'avoir tous ces enregistrements ?


- Les tables sont elles lourdes ? (environ combien de lignes)



- Sont elles bien indexées ?

ok j'ai bien établi les INDEX dans Php My Admin

de toutes les requetes, rien que cette manipulation Exemple :

Avant sur Mysql 5.7 1,2 secondes pour lire le script
Maintenant Mysql 8.0 avec les index établis 0,480 secondes !

Pour conclure, en effet l'index joue un rôle plus que essentiel je n'aurais pas pensé autant ! Merci à vous le problème est résolu.

Bonjour,

pour ceux qui veulent plus de détails et de la doc : https://dev.mysql.com/doc/refman/8.0/en/mysql-indexes.html
+ https://www.percona.com/blog/understanding-mysql-indexes-types-best-practices/
+ https://www.digitalocean.com/community/tutorials/how-to-use-indexes-in-mysql

Et du coup les première lignes qui explique le pourquoi du comment :
[quote]
Indexes are used to find rows with specific column values quickly. Without an index, MySQL must begin with the first row and then read through the entire table to find the relevant rows. The larger the table, the more this costs. If the table has an index for the columns in question, MySQL can quickly determine the position to seek to in the middle of the data file without having to look at all the data. This is much faster than reading every row sequentially.
[/quote]

Cordialement, janus57