J'ai une requête en cours d'exécution sur Maridb, lorsque nous interrogeons dans l'ordre ASC, l'optimiseur vérifie moins de nombre d'enregistrements (r_rows) et termine la requête en 500 ms environ, mais lors du passage de l'ordre à DESC, la même chose La requête prend plus de temps à terminer et le r_rows est d'environ 2,27 millions.
Pourquoi est-ce ? Pourquoi l’ordre ASC/DESC affecte-t-il les performances des requêtes ?
Il s'agit d'une requête SQL
SELECT x_nuvo_eam_scheduled_m9e_e8s0.`sys_id` FROM ( x_nuvo_eam_scheduled_m9e_e8s x_nuvo_eam_scheduled_m9e_e8s0 LEFT JOIN x_nuvo_eam_scheduled_m10s x_nuvo_eam_scheduled_maintena1 ON x_nuvo_eam_scheduled_m9e_e8s0.`scheduled_maintenance` = x_nuvo_eam_scheduled_maintena1.`sys_id` ) WHERE x_nuvo_eam_scheduled_m9e_e8s0.`status` = 'Pending' AND x_nuvo_eam_scheduled_m9e_e8s0.`scheduled_date` >= '2022-02-15 06:00:00' AND x_nuvo_eam_scheduled_maintena1.`asset` IS NULL ORDER BY x_nuvo_eam_scheduled_m9e_e8s0.`sys_created_on` ASC limit 0, 100
Les 2 sorties d'analyse MariaDB suivantes montrent le plan d'exécution
La requête ordonnée ASC se termine en ~ 503 ms
+---------+------------------------------------------------------------------------------------------------------------------------ | 1 result(s): +---------+------------------------------------------------------------------------------------------------------------------------ | ANALYZE | { | | "query_block": { | | "select_id": 1, | | "r_loops": 1, | | "r_total_time_ms": 503.93, | | "table": { | | "table_name": "Table_A", | | "access_type": "index", | | "possible_keys": ["idx1"], | | "key": "sys_created_on", | | "key_length": "6", | | "used_key_parts": ["sys_created_on"], | | "r_loops": 1, | | "rows": 2695302, | | "r_rows": 234328, | | "r_total_time_ms": 476.64, | | "filtered": 50, | | "r_filtered": 0.1903, | | "attached_condition": "Table_A.`status` = 'Pending' and Table_A.scheduled_date >= '2022-02-15 06:00:00'" | | }, +---------+------------------------------------------------------------------------------------------------------------------------
Requête ordonnée DESC ASC terminée ~9118 ms
r_rows significantly Larger as comparing to ASC. +---------+----------------------------------------------------------------------------------------------------------------------- | 1 result(s): +---------+----------------------------------------------------------------------------------------------------------------------- | ANALYZE | { | | "query_block": { | | "select_id": 1, | | "r_loops": 1, | | "r_total_time_ms":9118.4, | | "table": { | | "table_name": "Table_A", | | "access_type": "index", | | "possible_keys": ["idx1"], | | "key": "sys_created_on", | | "key_length": "6", | | "used_key_parts": ["sys_created_on"], | | "r_loops": 1, | | "rows": 2695302, | | "r_rows": 2.27e6, | | "r_total_time_ms": 4380.1, | | "filtered": 50, | | "r_filtered": 70.102, | | "attached_condition": "Table_A.`status` = 'Pending' and Table_A.scheduled_date >= '2022-02-15 06:00:00'" | | | }, +---------+-----------------------------------------------------------------------------------------------------------------------
Suggestions d'optimisation d'index
Index des tableaux x_nuvo_eam_scheduled_m9e_e8s (statut, date_programmée, maintenance_programmée, sys_created_on) x_nuvo_eam_scheduled_m10s (sys_id)
Ensuite, modifié pour ne pas avoir (parens) et
ticks
, mais également utiliser un alias plus propre maintenu par planifié vs. Il sera utile d'avoir la première table avec les index appropriés pour optimiser les critères WHERE et JOIN. Mais la création d'un index de couverture complet facilitera également les requêtes car tous les éléments peuvent provenir de l'index au lieu de revenir à la page de données d'origine pour chaque table.