MySQL - Problème de performance lors de la mise à niveau de 5.5.27 à 5.7

Question

Je travaille sur une requête qui récupère la liste des rapports de service avec ses détails. La requête renvoie également le rapport de service qui manque dans la base de données en mettant '-' dans la colonne des détails. Après avoir passé quelque temps là-dessus, je suis venu avec une requête comme celle-ci: -

select 
    22000+n as sSrn ,IFNULL(m.mType,'---') machineType, ifnull(c.custName,'---') as customerName,  IFNULL(sDos,'---') DateOfService , IFNULL(sSrgd,'---') AS ServiceRptDate ,IFNULL(sTechnician,'---') AS technician ,IFNULL(CAST(sPcdescription AS char(100)) ,'---') AS remarks , IFNULL(CAST(m.machineID AS char(100)) ,'---') AS machineID 
from 
    (
    SELECT @curRow := @curRow + 1 AS n 
    FROM  service CROSS JOIN dummytable 
    JOIN (SELECT @curRow := 0) r 
    ) numbergen 
LEFT JOIN service s ON sSrn = 22000+n 
LEFT JOIN machine m ON s.machineID = m.machineID  
LEFT JOIN customer c ON c.custID = m.custID 
LIMIT 0,10 

La requête génère en fait une table avec beaucoup de lignes et de le comparer avec les données de la table de service. Si le numéro de service n'est pas consécutif, il générera le numéro de rapport manquant avec '-' comme autres colonnes. Et le résultat idéal est accompli, qui est comme ceci.

Mais le problème est que la requête est en cours d'exécution très lentement quand je mets à jour la version MySQL à 5.7 lorsque l'on compare à 5.5.27 (5.5.27 donne également une performance moyenne, mais encore utilisable.)) pour exemple:

secondes se sont écoulées pour MySQL 5.5.27: 1,48 SEC ** secondes ** se sont écoulées pour MySQL 5.7: 14,960 SEC

Dites-nous comment améliorer les performances des requêtes dans MySQL 5.7 ou SQL.

NOTE: Je comprends également que le tri automatique basé sur la première colonne ne fonctionne pas sur 5.7 ce qui me fait passer une commande dans la requête, ce qui entraîne plus de retard.

MISE À JOUR: expliquiez 5.5.27 Version

EXPLIQUER pour la version 5.7

Answer 1

différence de performance 10x sent comme en cache vs non-cache. Exécutez chaque test de synchronisation deux fois; ignore le premier. (Cela suppose que le cache de la requête n'est pas activé.) Si ce n'est pas le cas, veuillez indiquer EXPLAIN SELECT ... pour les deux versions.

Puisque vous utilisez probablement les "séquences" fréquemment, pourquoi ne pas construire une table permanente avec les nombres 1 ... (une grande valeur). Ensuite, vous pouvez dire FROM numbers ... WHERE n BETWEEN 1 AND 10 (et laisser le LIMIT).

Si vous utilisiez MariaDB, cette 'table' peut être générée dynamiquement via la pseudo-table seq_1_to_10. Ou, peut-être mieux: seq_22001_to_22010 et d'éviter le 22000+.