J'écrirais la requête comme ceci :
SELECT c.time
, SUM(c.counter)
, MAX(p.clustername) AS clustername
FROM cell c
JOIN swap_plan p
ON p.siteid = c.siteid
AND p.clustername = 'Cluster A'
WHERE c.time >= 'day1'
AND c.time <= 'day2'
GROUP
BY c.time
Je serais sûr d'avoir un index sur cell avec time comme colonne de tête.
MySQL peut utiliser le même index pour satisfaire le prédicat de plage (dans la clause WHERE) et pour satisfaire le GROUP BY sans opération "Using filesort".
... ON cell (time)
Selon la taille des colonnes, un index de couverture peut donner des performances optimales. Un index de couverture inclut toutes les colonnes de la table qui sont référencées dans la requête, de sorte que la requête peut être entièrement satisfaite à partir des pages d'index sans rechercher les pages de la table sous-jacente.
... ON cell (time, siteid, counter)
Pour l'index sur swap_plan , j'aurais un index avec site_id comme colonne de tête, et incluant le clustername colonne, l'une des suivantes :
... ON swap_plan (clustername, site_id)
ou
... ON swap_plan (site_id, clustername)
Il semble probable qu'il y aura une contrainte UNIQUE sur la combinaison de ces deux colonnes, c'est-à-dire les valeurs de site_id sera distinct pour un clustername donné . (Si ce n'est pas le cas, et le même (site_id,clustername) tuple apparaît plusieurs fois, il y a un potentiel pour un total agrégé de counter à gonfler.
Je chercherais le EXPLAIN sortie pour afficher une recherche 'ref' vers swap_plan table à partir de la valeur de c.siteid et const (littéral 'Cluster A') valeur pour clustername.
Avec des tables dimensionnées à 31 lignes et 368 lignes, nous n'allons pas voir une différence significative de performances (temps écoulé) entre un plan d'exécution optimal et un plan d'exécution horrible.
Lorsque l'une des tables évolue jusqu'à des millions de lignes, c'est à ce moment-là que les différences deviennent apparentes. Le choix du plan d'exécution des optimiseurs est influencé par les statistiques (taille, nombre de lignes, cardinalité des colonnes) de chaque table, de sorte que le plan d'exécution peut changer avec une augmentation de la taille des tables.
