Quelle est la gravité de ma requête ?

Question

Ok j'ai besoin de construire une requête basée sur certains saisie de l'utilisateur pour filtrer les résultats.

La requête de coeur va quelque chose comme ceci:

SELECT * FROM my_table ORDER BY ordering_fld;

Il y a quatre zones de texte dans lequel les utilisateurs peuvent choisir de filtrer les données, ce qui signifie que je devrais générer dynamiquement une clause "where" en elle pour la première filtre utilisé et puis "ET" clauses pour chaque filtre d'entrée.

Parce que je suis trop paresseux pour ce faire, j'ai juste fait chaque filtre est un "ET" de la clause et de mettre un "1" clause dans la requête par défaut.

Alors maintenant, j'ai:

SELECT * FROM my_table WHERE 1 {AND filters} ORDER BY ordering_fld;

Donc ma question est, ai-je fait quelque chose qui va nuire à la performance de ma requête ou enculer rien d'autre de toute manière, je devrait être à distance de m'inquiéter?

Answer 1

MySQL permettra d'optimiser votre 1 loin.

J'ai juste couru cette requête sur ma base de données de test:

EXPLAIN EXTENDED
SELECT  *
FROM    t_source
WHERE   1 AND id < 100

et il m'a donné la suivante description:

select `test`.`t_source`.`id` AS `id`,`test`.`t_source`.`value` AS `value`,`test`.`t_source`.`val` AS `val`,`test`.`t_source`.`nid` AS `nid` from `test`.`t_source` where (`test`.`t_source`.`id` < 100)

Comme vous pouvez le voir, pas de 1 à tous.

La documentation sur WHERE clause d'optimisation en MySQL mentionne ceci:

• De constantes:

  (a<b AND b=c) AND a=5
  -> b>5 AND b=c AND a=5
  

• Constante de la suppression des conditions (nécessaires en raison de la constante de pliage):

  (B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6)
  -> B=5 OR B=6
  

Note 5 = 5 et 5 = 6 des pièces dans l'exemple ci-dessus.

Answer 2

Vous pouvez EXPLAIN votre requête:
http://dev.mysql.com/doc/refman/5.0/en/explain.html

et voir si elle fait quelque chose de différent, ce dont je doute. J’utiliserais 1-1, juste pour qu’il soit plus clair.

Vous voudrez peut-être ajouter LIMIT 1000 ou quelque chose, quand aucun paramètre n’est utilisé et la table devient grande, voulez-vous vraiment tout retourner?

Answer 3

``est une expression constante et déterministe qui sera « optimisée » par n’importe quel moteur DB décent.

Answer 4

Si il ya une bonne façon dans la langue de votre choix pour éviter de construire SQL vous-même, utiliser à la place. J'aime Python et Django, et l'ORM de Django, il est très facile de filtrer les résultats en fonction de l'entrée utilisateur.

Si vous vous êtes engagé à la construction du SQL, assurez-vous de désinfecter les entrées de l'utilisateur contre les injections SQL, et essayer de les encapsuler SQL bâtiment dans un module séparé de votre filtre de la logique.

Aussi, les performances de la requête ne doit pas être votre préoccupation, jusqu'à devenir un problème, il ne sera probablement pas jusqu'à ce que vous avez des milliers ou des millions de lignes. Et quand viendra le moment de les optimiser, en ajoutant quelques indices sur les colonnes utilisées pour OÙ et REJOIGNEZ va un long chemin.

Answer 5

Pour améliorer les performances, utilisez des index de colonnes sur les champs écouter dans "Où"