J'ai une table A qui a une startDate et une fin daturonnée sous forme de 2 colonnes DateTime, outre quelques autres colonnes. J'ai une autre table B qui a une colonne DateTime appeler la colonne Dates. Ceci est dans SQL Server 2005.
Voici la question: comment mieux configurer les index, etc. pour obtenir ce qui suit: Les deux tables ont plusieurs milliers de documents.
10 Réponses :
Si vous devez optimiser, essayez d'exécuter cette requête dans l'analyseur de requête.
Chaque version de SQL Server 2000, 2005, 2008 dispose d'un programme appelé conseiller à syntonisation de la base de données lorsque vous exécutez une question, il vous indique les index dont vous avez besoin pour ajouter la requête plus rapidement. Meilleures salutations, Iordan
Vous avez besoin de 3 index A.Startdate, B.Dates et A.ENDDate, peut être index (A.ENDATE + A.StartDate) est également bon. Je n'ai aucun détail sur une autre colonnes et objectifs pour ces tables, mais examiner la possibilité d'utiliser l'index en cluster.
Dans l'utilisation de toute façon "Plan d'exécution" d'utilisation pour prendre la décision entre toutes ces variantes, car ma suggestion est trop générale
Le script suivant répertoriera les indices manquants possibles (vous pouvez filtrer l'instruction par T.Name).
J'ajouterais simplement un index en cluster sur B.Dates. Si vous ajoutez des index sur startdate et que vous n'achèterez rien d'autre que vous obtiendrez des analyses d'index sur un. L'indice en cluster sur B vous permet de rechercher au moins un index. Une balayage de table et une analyse d'index sont la même chose, il est donc utile d'ajouter des index pour obtenir l'analyse de la table de mots de votre plan d'exécution :)
Je me moquerais de quelques façons de voir si vous pouvez refaire votre requête pour ne pas nécessiter une analyse de table sur laquelle je devine n'est pas vraiment possible.
"Une analyse de table et une analyse d'index sont la même chose"? Je ne le pense pas, sauf si vous voulez dire lorsque l'index a toutes les colonnes de la table. Je doute fort que ses tables ne disposent que de les colonnes mentionnées.
Oui, il s'agit de la même chose. Une analyse d'index récupère chaque rangée d'une table pendant la recherche. Une balayage de table (ou une numérisation d'index) où est Aucun autre index en cluster sur la table ne vous donne la pire performance.
Une analyse d'index récupère toutes les "lignes" de l'index, pas la table. Une analyse d'index est meilleure qu'une numérisation de table simplement car un index comporte normalement moins de colonnes que la table, ce qui donne plus de "lignes" par lecture. Mais nous convenons que les analyses sont mauvaises et d'être évitées.
L'OP a déclaré que la table en question n'aurait donc que quelques milliers de lignes qu'elle a donc douteuses que quiconque remarque une différence de vitesse de requête en raison des implications que vous discutez ici. Je me suis moqué de quelques exemples et je n'ai vu aucune différence sur la taille de données que l'OP discutait lorsque j'ai essayé des index non clusters et clusters sur les différentes colonnes de Tablea référencées.
Comme nous ne savons pas quelles autres colonnes la table a et quelles sont les autres requêtes terminées, nous ne pouvons pas dire si la mise en place d'un index en cluster serait utile
@Ian: bon point. Il est également possible qu'il y ait déjà un sur cette table, mais si la table a juste des dates, il devrait être utile.
Un peu plus d'informations est nécessaire. Combien d'autres colonnes sont dans les tables? Ces tableaux existants sont-ils avec beaucoup de requêtes qui vont déjà contre eux, ou toutes les nouvelles tables? Quel genre de problème de performance voyez-vous que vous souhaitez poser la question?
Je suppose que les trois colonnes ne sont pas nulles (pas seulement pour la syntaxe de la requête, mais pour l'utilité de l'index).
Je commencerais avec un index composé sur A.StartDate + A.ENDDate, et un autre index sur B.Dates (mais cela n'est probablement pas nécessaire). À moins que ces dates soient le principal objectif des tables, j'éviterais de créer des indices en cluster sur ces colonnes. Ceci est doublement vrai si ces tables sont des tables existantes avec d'autres requêtes qui courent contre eux. Les requêtes précédentes peuvent être écrites à l'attente des indices en cluster existants.
J'ai travaillé sur deux sociétés (à la fois des systèmes de gestion du temps et de la fréquentation) qui ont beaucoup de fois avec les colonnes de démarrage et deddate. Dans mon expérience, il n'y a pas de bons index qui toujours fonctionne avec les chaînes de date .
Essayez des index comme (startdate, -unddate) et (-undDate, startdate) pour voir s'ils aident, Essayez également d'utiliser un index qui couvre toutes les colonnes qui se trouvent dans votre relevé "Où", SQL n'a donc pas besoin de lire la table principale tant qu'il n'a pas élaboré quelles lignes reviennent.
vous mai doit utiliser des indices d'index, car il est peu probable que le processeur de requête connaisse suffisamment sur les données pour faire un bon choix d'index - c'est l'une des Élargir les données, vous disposez donc d'une table contenant (date, ramée) avec une ligne de chaque date dans la plage de date mai être nécessaire. Cependant, garder le tableau "Index" mis à jour est une douleur.
Si vous savez que certaines de vos gammes de date ne se chevauchent pas, consultez Utilisation de croix Appliquer pour optimiser les jointures entre les conditions (par exemple, les records de maladie d'un employé ne peuvent pas être autorisés à se chevaucher) / p>
En fin de journée si vous n'avez que plusieurs milliers de disques, une numérisation de table complète n'est pas trop mauvaise.
Sujets Quassnoi utilisant des indices spatiaux , je n'ai aucune expérience des indices spatiaux" abusifs "de cette manière, mais je pense que cela vaut la peine d'essayer. Cependant, faites très attention si vous aurez à tous les fournisseurs de base de données multiples de support, car l'indice spatial est plutôt nouveau. De plus, vous avez peut-être toujours besoin des colonnes de date pour les outils de rapport, etc.
(tôt ou tard aura besoin de pouvoir trouver toutes les lignes qui chevauchent une plage de dates, alors il devient encore plus difficile d'obtenir des index qui renvoie de bons résultats.)
J'irais avec ce
Cela ne fonctionnera que bien pour les requêtes de poignardage. Au fait, longtemps, pas de voir. Les forums Artima sont partis
Mise à jour: strong> Voir cet article sur mon blog pour une stratégie d'indexation efficace pour votre requête à l'aide de colonnes calculées: p> L'idée principale est que nous consacre simplement à calculer code> longueur code> et in Ils sont particulièrement bons pour les conditions telles que "Sélectionner tous les enregistrements avec un point donné à l'intérieur de la plage de l'enregistrement", qui est juste votre Cas. P> Vous stockez le Voir cette entrée dans mon blog sur la façon de faire cela dans et une brève vue d'ensemble de performances pour la même solution peut être appliquée pour la recherche d'un Cette tâche, avec votre requête, est une autre. Utilisé d'exemple d'une telle condition. P> uni S'ils ne peuvent pas (et vous le savez ), vous pouvez utiliser la solution brillante proposée par Notez également que cette performance de requête dépend totalement de votre distribution de données. P> Si vous avez beaucoup d'enregistrements dans Cette requête lira toujours toutes les lignes de Si vos données sont distribuées dans une autre voie, i. e. Vous avez beaucoup de lignes dans
startdate code> pour vous, puis recherchez-les à l'aide des conditions d'égalité (qui sont bonnes pour B-Tree Code> index) P>
MySQL code> et dans SQL Server 2008 code> Vous pouvez utiliser spatial index ( r-arbre code>). p> start_date code> et end_date code> comme début et fin d'un linetring code> (la convertir sur Unix code> horodarestampes d'une autre valeur numérique), indexez-les avec un index code> spatial CODE> et recherchez tous ces linetring code> S dont la boîte de sélection minimale ( MBR code>) contient la valeur de date en question, à l'aide de MBRContails code>. p> MySQL code>: p>
mySQL code> SQL Server code>: p>
SQL Server Code> strong> li>
ul> IP code> par rapport à des gammes réseau stockées dans la base de données. P> B-Tree code> Les index ne sont pas bons si les plages peuvent se chevaucher. p> @alexkuznetsov code> p> B code> et quelques enregistrements dans A code>, vous pouvez simplement créer un index sur b.dates code> et laisser le ts / cis code> sur A code> go. p> A code> et utilisera indexer la recherche code> sur b.dates code> dans une boucle imbriquée. p> A code> mais peu dans B code>, et les gammes sont généralement courtes, vous pourriez désigner vos tables un peu: P> SELECT *
FROM (
SELECT DISTINCT interval_length
FROM a
) ai
CROSS JOIN
b
JOIN a
ON a.interval_length = ai.interval_length
AND a.start_date BETWEEN b.date - ai.interval_length AND b.date
Ceci est la première raison que j'ai vue pour avoir créé des logiciels dépend de SQL Server 2008 (plutôt de 2005)
Je ne sais pas à quel point l'indice spatial se combine avec d'autres types d'index, par exemple "Où département = 123 et chevauche Sickleave chevauchent WorldCub"
@ian : Dans SQL Server , les index seront utilisés, puis fusionnés à l'aide d'une méthode de fusion appropriée (probablement match de hasch )
Désolé, ce que je voulais dire était, je pourrais créer un indice sur (Ministère, MalnessTartDate), puis si je faisais une recherche de tout employé dans un département qui était malade à un moment donné, l'indice peut être utilisé. Cependant, puis-je créer "composé" (pour manque d'un mot de meilleur mot) incluant des arbres R?
@Ian : Vous ne pouvez pas. B-Tree Index s'appuie sur le tri et le tri sur (col1, col2, com3) implique le tri sur (col1, col2) et Col1 , donc avec B-Tree , vous obtenez 3 index pour le prix d'un. Ce n'est pas le cas pour r-arbre .