pour de meilleures performances, vous pouvez essayer d'utiliser l'index composite .. basé sur la colonne impliquée dans votre clause where
et essayez de modifier la clause IN dans une jointure interne
en supposant que le contenu de votre clause IN est un ensemble de valeurs fixes vous pouvez utiliser union (ou une nouvelle table avec la valeur dont vous avez besoin)
par exemple en utilisant l'union (vous pouvez faire quelque chose de similaire si la clause IN est une sous-requête)
select user_table.colA ,ColB , count(*) as count
from user_table
INNER JOIN (
select 'FIXED1' colA
union
select 'FIXED2'
....
union
select 'FIXEDX'
) t on t.colA = user_table.colA
where colC >='2019-09-01 00:00:00'
and ColB = 17
group by colA ,ColB;
vous pouvez également ajouter un index composite sur la table user_table sur les colonnes
colA, colB, colC
pour ce qui est lié à l'élément utilisé par l'optimiseur de requête mysql pour décider de l'index à utiliser, plusieurs aspects et pour tous, l'optimiseur de requête attribue un coût
tout ce que vous devez prendre en considération
- la colonne impliquée dans la clause Where
- La taille des tables (et non pas la taille des tables dans la jointure)
- Une estimation du nombre de lignes qui seront récupérées (pour décider d'utiliser un index ou simplement parcourir la table)
- si les types de données correspondent ou non entre les colonnes de la clause jion et where
- L'utilisation d'une fonction ou d'une conversion de type de données, y compris l'erreur de classement
- La taille de l'index
- cardinalité de l'index
et pour l'ensemble de ces options est évalué un coût et cela conduit à l'index choisir
Dans votre cas, le colC comme date pourrait impliquer une conversion de données (respectez les valeurs littérales comme chaîne ) et pour cela l'index n'est pas choisi ..
C'est aussi pour cela que j'ai proposé un index composite avec la colonne la plus à gauche liée aux valeurs non converties
