|
MySQL est un système open source de base de données relationnelle de gestion (SGBDR) . En raison de sa faible dépense , les organisations sont de plus en plus l'utilisent pour les grandes bases de données. Plus la base de données, l' une requête plus probable sera de retour de nombreux doublons , ce qui rend la sortie difficile à lire et la lenteur de la requête. En utilisant le mot-clé DISTINCT dans vos instructions SELECT peut éliminer ces doublons dans votre sortie . Pourquoi vous obtenez des résultats en double
Habituellement , une requête n'affiche pas toutes les colonnes de la table ou de tables qu'il référence. Un employeur peut , par exemple, avoir un tableau qui permet de suivre les absences des employés . S'il veut savoir quels employés ont eu au moins une absence dans le dernier mois , il pourrait utiliser une requête qui ressemble à ceci :
SELECT employees.first_name , les employés de employees.last_nameFROM , absencesWHERE employees.employee_id = absences.employee_idAND absences.date > = ' JUN -01- 09' ;
Si Bob Smith était absent pendant trois jours en Juin , les résultats de la requête contiennent trois rangées de Bob Smith. Même si la requête n'affiche pas la date, depuis trois absences de Bob étaient à des dates différentes , cette requête renvoie chacune des trois lignes.
Pourquoi Résultats en double sont Bad
< p> Les lignes dupliquées non seulement rendre votre sortie difficile à lire, ils ralentissent également votre requête et ressources de base de données de porcs. Sauf si votre base de données est très faible, vous avez probablement développer vos scripts SQL dans une instance de base de développement qui est distinct de votre instance de production . Il n'est pas du tout rare pour les instances de développement d'avoir beaucoup moins de données en eux que l'instance de production.
Si vous autorisez les doublons dans votre sortie , vous effectuez votre recherche de base de données tout au long de toute l' tables que vous avez réunis dans votre requête. Cela peut faire une requête qui a couru assez vite dans votre instance dev lent à une exploration à la production. Si votre base de données de production est grande, votre requête peut fonctionner pendant des heures
utilisation et optimisation DISTINCT
Les rendements suivants sélectionnez une des lignes pour Bob Smith: .
SELECT DISTINCT employees.first_name , les employés de employees.last_nameFROM , absencesWHERE employees.employee_id = absences.employee_idAND absences.date ENTRE '2009 -06- 01 ' ET '2009 -07- 01' ;
vos résultats sont plus faciles à lire, mais votre serveur de base de données doit encore travailler trop dur si votre table employee a beaucoup plus de lignes que votre table absences. . MySQL va parcourir chaque enregistrement de la table des employés pour voir si cet employé a des absences
Au lieu de cela , faire œuvre distincte pour vous de faire votre requête plus efficace :
SELECT DISTINCT employees.first_name , les employés employees.last_nameFROM , absencesWHERE absences.employee_id = employees.employee_idAND absences.date > = ' JUN- 01-09 ';
Cette requête aura un enregistrement dans la table des absences et arrêter de chercher la table employee une fois qu'il trouve l'employé qui va avec cette absence. Votre requête sera lancé uniquement autant de recherches car il ya des absences , et va chercher à travers beaucoup moins de la table des employés de chaque catégorie. Il utilise moins de ressources de base de données et tourne beaucoup plus vite .
|
