2009-10-12 6 views
2

j'ai cette requête syndicale:Index sur requête UNION?

(SELECT INSTALLER, INSTALLTIME, RESULT, JOBNUMBER, HONAME, ADDRESS, CITY, STATE, ZIP, NOTES, SMNOTES, '' as priority, PAFS, upsell, TERM, MMRUPGRADE, WARRANTY, EFT FROM ACCOUNTS 
WHERE INSTALLDATE = '$date' && FUNDINGSTATUS !='DEAD') 
UNION 
(SELECT technician, servicetime, result, ID, Customername, address, city, state, zip, notes, board, priority, '', '', '', '', '', '' FROM service 
WHERE serviceday = '$date') 
ORDER BY INSTALLER, priority 

je suis curieux de savoir si vous ajoutez un index sur le champ de date permettra d'accélérer les requêtes? ou est-ce que le fait que j'utilise FUNDINGSTATUS dans la première clause where fera que cette requête n'utilise pas l'index?

Répondre

2

Répondre à votre question très:

Je suis curieux de savoir si mettre un index sur le champ de la date permettra d'accélérer les deux requêtes?

Si la condition sur installdate et serviceday est sélectif (qui est peu de lignes le satisfont), alors oui, il vous aidera.

Les champs de date ont généralement tendance à être sélectifs.

ou est-ce que le fait que j'utilise FUNDINGSTATUS dans la première clause où cette requête n'utilisera pas l'index?

Oui, l'index sera toujours utilisé.

Le moteur utilisera l'index pour sélectionner uniquement les enregistrements avec installdate = $date et le filtre sur la valeur de fundingstatus.

Pour de meilleurs résultats, créez les indices suivants:

ACCOUNTS (installdate, fundingstatus) 
service (serviceday) 

Si DEAD est une valeur fréquente pour fundingstatus, il peut être préférable de réécrire cette requête comme ceci:

SELECT INSTALLER, INSTALLTIME, RESULT, JOBNUMBER, HONAME, ADDRESS, CITY, STATE, ZIP, NOTES, SMNOTES, '' as priority, PAFS, upsell, TERM, MMRUPGRADE, WARRANTY, EFT 
FROM ACCOUNTS 
WHERE INSTALLDATE = '$date' AND FUNDINGSTATUS < 'DEAD' 
UNION ALL 
SELECT INSTALLER, INSTALLTIME, RESULT, JOBNUMBER, HONAME, ADDRESS, CITY, STATE, ZIP, NOTES, SMNOTES, '' as priority, PAFS, upsell, TERM, MMRUPGRADE, WARRANTY, EFT 
FROM ACCOUNTS 
WHERE INSTALLDATE = '$date' AND FUNDINGSTATUS > 'DEAD' 
UNION 
SELECT technician, servicetime, result, ID, Customername, address, city, state, zip, notes, board, priority, '', '', '', '', '', '' 
FROM service 
WHERE serviceday = '$date' 
ORDER BY 
     INSTALLER, priority 

de sorte que la l'accès à la plage sur les deux champs (installdate, fundingstatus) peut être utilisé.

+0

Bien que ce soit correct, il ne répond pas réellement à la question qu'il a posée. –

+0

DEAD n'est pas encore fréquent, mais ce sera le cas. il y aura aussi éventuellement 6 à 7 autres statuts de financement. Je suis juste curieux, comment l'accès à la gamme aide-t-il (ou plus alors, comment ça marche). Je viens de faire des recherches sur mysql ces derniers temps et je n'ai rencontré le terme que quelques fois. – mlebrun15

+0

L'accès à la gamme est plus cher ** par ligne ** (en règle générale, 10 fois plus cher). Cela signifie que si votre condition filtre 90% de lignes de plus, alors l'accès 'range' sera meilleur. – Quassnoi

3

Il est fort probable que cela aidera, mais la seule façon d'être sûr est de casser le profileur et d'y jeter un coup d'œil. Depuis la version 5.0.37, MySQL a un profiler intégré.

Activer avec

set profiling=1; 

Pour rechercher la query_id

show profiles; 

Et pour voir le plan d'exécution:

show profile for query x; 
0

Avoir l'index sur n'importe quel champ dans la clause where peut toujours améliorer les performances, que ce soit par beaucoup ou un peu.

Pour répondre à votre question de savoir si l'index « date » sera utilisé malgré première requête ayant « FUNDINGSTATUS » dans la clause where a 2 réponses:

  • S'il n'y a pas d'index AUTRES sur la table , alors l'index de date sera certainement utilisé.C'est parce que trouver des enregistrements avec la date spécifique par index est beaucoup moins de travail pour la base de données que la recherche de la table entière, même si elle doit vérifier le FUNDINGSTATUS après avoir trouvé lesdits enregistrements.

  • S'il existe d'autres index sur la même table, la réponse est "cela dépend".

    Cela dépend en grande partie de ce% de données qui ne sont pas données par rapport à% des données pour une date donnée.

    L'optimiseur essaie généralement de choisir l'index qui sélectionne immédiatement le plus petit nombre de colonnes - par ex. Si votre table a des données pour 100 jours et que la moitié d'entre elles sont des lignes mortes, alors l'index de date sera choisi car il vous donne 1% des données sans balayer la table contre 50% des données.