6
votes

Pourquoi utiliser IN (...) lorsque vous sélectionnez sur les champs indexés, tuera les performances de la requête SELECT?

Évitez d'utiliser dans (...) lors de la sélection des champs indexés, il tuera les performances de la requête SELECT.

J'ai trouvé ceci ici: https://wikis.oracle.com/pages /viewpage.action?pageID=27263381

Pouvez-vous l'expliquer? Pourquoi cela va tuer la performance? Et que dois-je utiliser au lieu d'entrer. "Ou" déclaration peut-être?


0 commentaires

4 Réponses :


-1
votes

Je crois que dans est traité de la même manière qu'un groupe d'ORS, il suffit donc d'utiliser des ours ne vous aidera pas.

Une alternative consiste à créer une table temporaire pour contenir les valeurs de votre clause, puis rejoindre ce temporaire Tableau dans votre sélection. p>

Par exemple: P>

CREATE TEMPORARY TABLE temp_table (v VARCHAR)

INSERT INTO temp_table  VALUES ('foo')
INSERT INTO temp_table  VALUES ('bar')

SELECT * FROM temp_table tmp, orig_table orig
WHERE temp_table.v = orig.value

DROP TEMPORARY TABLE temp_table


0 commentaires

2
votes

Parce que MySQL ne peut pas l'optimiser.

Voici un exemple: xxx

plan ( Désolé pour le lien externe. Ne montre pas correctement ici)

Voici une autre requête: xxx

plan

Comme vous pouvez le voir dans la deuxième requête que nous obtenons ref comme const et Type est Const au lieu de la plage. MySQL ne peut pas optimiser les analyses de la plage.


3 commentaires

Néanmoins, la deuxième requête semble prendre plus de temps, au moins, sur mes jeux de données.


@Newtover Ceci s'applique uniquement "lors de la sélection des champs indexés"


J'ai également examiné Amazon.com/high-performance-mysql- Optimisation-réplication / d p / ... , et il indique que la sortie de l'explication peut parfois rendre difficile de dire si MySQL recherche vraiment une gamme de valeurs ou pour une liste de valeurs. ... nous "Ne pas simplement être difficile: ces deux types d'accès d'index fonctionnent différemment. La condition de gamme permet à MySQL ignore les autres colonnes de l'index, mais la condition multiple d'égalité n'a pas cette limitation."



3
votes

Pour dire la vérité, cette déclaration contredit à de nombreuses notes que j'ai lu dans des livres et des articles sur MySQL.

Voici un exemple: http://www.mysqlperformanceblog.com/2010/01/09/geting-around-optimizer-limitations-with-an-in-list/

De plus, Expr in (valeur, ... ) elle-même a des améliorations supplémentaires pour traiter avec de grandes listes de valeurs, car elle est supposée être utilisée comme alternative utile à certains Plage requêtes:

Si toutes les valeurs sont des constantes, elles sont évaluées en fonction du type d'expr et triées. La recherche de l'élément est ensuite effectuée à l'aide d'une recherche binaire. Cela signifie que dans est très rapide si la liste de valeur est entièrement consiste en des constantes.

Nomeutrage toujours sur les normes peut entraîner des requêtes lentes. Certains cas sont notés dans L'article . < / p>


0 commentaires

0
votes

Avant MySQL 5.0 Il semble que MySQL n'utiliserait qu'un seul index pour une table. Donc, si vous aviez un SELECT * de TBL où (A = 6 ou B = 33) Il pourrait choisir d'utiliser l'index ou l'index B, mais pas tous les deux. Notez qu'il dit des champs, pluriel. Je soupçonne que les conseils viennent de cette époque et le travail autour de l'union du ou des résultats, comme: xxx


0 commentaires