Ceci est une table de fait il a un indice composite comme suit Dans cette structure, toutes les colonnes VARCHAR 10 ont uniquement des valeurs numériques. Est-ce que cela va être bénéfique pour moi de changer cette structure de 78 millions de lignes pour contenir de la Bigint au lieu de Varcharne en termes d'interrogation et d'indexation? Tout autre avantage / inconvénients que je devrais envisager?
3 Réponses :
Vous devriez Cette touche principale / clé en cluster sur SQL Server sera de 64 octets de taille maximale (au lieu de 4, pour un INT) - qui rendra votre index en cluster et tout votre indice non clustered balloté au-delà de la reconnaissance. Toute la clé de clustering (toutes vos 8 colonnes) sera incluse sur chaque page de chaque index non mis en cluster sur cette table - gaspillage de lots et beaucoup d'espace à coup sûr.
Ainsi, sur une table d'index donnée, vous auriez jusqu'à 16 fois plus d'entrées avec une clé de plate-forme de substitution, ce qui signifie beaucoup moins d'E / S, beaucoup de temps perdu de lecture de pages d'index.
et imaginez simplement essayer d'établir une relation de clé étrangère à cette table ... Toute table enfant devrait avoir toutes les colonnes à 78 millions de lignes, même en modifiant simplement la clé de clustering sur l'identité de INT vous permettra de sauvegarder jusqu'à 60 octets par rangée - que seuls sortiraient à 4 gbyte d'espace disque (et d'utilisation de la RAM sur votre serveur). Et cela ne commence même pas à calculer les économies sur les indices non clusters .......
Et bien sûr, oui, je changerais également le Varchar (10) sur INT ou BIGINT - s'il s'agit d'un nombre, rendez le champ Type numérique - tout à fait de le laisser à Varchar (10), vraiment. Mais cela seul ne va pas faire une énorme différence en termes de vitesse ou de performance - cela rend simplement fonctionnant avec les données beaucoup plus faciles (ne pas avoir à se lancer toujours sur des types numériques lorsque par exemple, comparer des valeurs, etc.). < / p>
marc int ITT () clé primaire !!
INT vous donne déjà potentiellement jusqu'à 2 milliards de lignes - n'est-ce pas assez ??
C'est une table de fait dans mon entrepôt de données. Il n'y a pas de tables utilisant le PK à partir de cela comme un FK.
@Raj: Ah, OK, cela explique quelques choses - vous avez oublié de mentionner cela. Mais toujours: avez-vous des indices non clusters sur cette table? Ceux qui seraient certainement extrêmement extrêmement d'avoir une seule clé primaire / clustering
Bigint utilise 64 bits pas d'octets, c'est-à-dire c'est deux fois plus grand, pas 16 fois.
@Yrlec: Oui, Bigint est 8 octets - GUID est 16 octets - deux fois plus grand. Mais la clé originale originale de l'OP composée de 8 colonnes allait comporter jusqu'à 64 octets de taille - c'est 16 fois plus grand qu'un int - c'est ce que je faisais appelé
Marc_s, merci! Quand commence-t-il à avoir un sens d'utiliser Bigint Versus Int pour mes colonnes d'identité? Si j'ai ~ 700 000 rangées dans une table et que je supprime et insérez toutes ces lignes une fois par semaine (sans réessie), je suis bon depuis 60 ans, mais si je le fais tous les jours (pas une exigence en ce moment), je 'M à 8 ans. J'envisage sérieusement en utilisant Bigint!
@JOHNB: INT vous donne au moins 2 rangées (ou même 4) milliards de lignes - vous devriez être en sécurité pendant un certain temps, je pense. :-) Plus: Vous pouvez toujours réexécuter votre table une fois par an dans le cadre d'un emploi de maintenance final.
marc s est juste en ce que la clé primaire 64 octets va être dupliquée dans chaque index de NC afin que vous alliez payer un coût d'E / S, ce qui aura une incidence sur la quantité de données tenue en mémoire (puisque Vous gaspillez votre espace sur une page d'index NC). Donc, sur cette base, la question n'est pas «devrais-je convertir mes varcharars», mais devrais-je envisager de convertir mon index en cluster à quelque chose de tout à fait différent ./
en termes de varchar vs le Bigint Il y a une bonne raison de convertir si vous pouvez vous permettre le temps; En dehors de la différence de stockage de 2 octets de stockage par champ, lorsque vous comparez des valeurs de deux types différents, SQL sera obligé de convertir l'un d'entre eux. Cela se produirait sur chaque comparaison, que ce soit pour une jointure d'index ou un prédicat dans une clause où.
Selon ce que vous sélectionnez les données par, quelles tables de dimensions sont jointes à la table de fait, vous pouvez récupérer des frais de conversion sur chaque requête, car elle doit rejoindre, car elle doit convertir un côté de celui-ci. .
Deux choses pouvant affecter les performances de l'index (et de la DB globale):
1) Taille de la page d'index 2) vitesse de comparaison
Donc, pour le premier, en général, plus votre page d'index / données est plus petite, plus vous pouvez conserver des pages dans la mémoire et plus la probabilité qu'une requête donnée soit en mesure de trouver la page dans le cache vs. lent disque. Ainsi, vous voudriez utiliser le plus petit type de données pouvant confortablement répondre à vos besoins futurs existants et proposés.
Bigint est 8 octets; Les Varcharis peuvent être plus petits si la taille des données est petite, de sorte que cela dépend vraiment de vos données. Cependant, 10 caractères longs de caractères peuvent être en mesure d'installer dans le type de données de SQL Server ( HTTP : //msdn.microsoft.com/en-us/library/ms187745.aspx ) Selon la taille, int contre Bigint dépend de votre domaine.
De plus, si votre ligne entière est d'une longueur fixe, certaines optimisations SQL Server peuvent faire en scan, car elle sait exactement où sur le disque la ligne suivante (en supposant que les lignes soient contiguës). Un cas de bord, pour être sûr, mais cela peut aider.
Pour le second, il est plus rapide de comparer les entiers que les chaînes Unicode. Donc, si vous ne stockez que des données de numéro, vous devez absolument basculer sur un type de données numérique de taille appropriée.
Enfin, Marc est correct que cela devient une clé primaire très compliquée. Toutefois, si vos données le garantissent - telles que celles-ci étant vos seules colonnes et que vous ne faites jamais de requêtes supplémentaires - vous pouvez parfaitement faire la version optimisée (avec de plus, etc.) votre clé primaire. Type d'odeur de code, cependant, je vais donc faire écho à son avis de regarder votre modèle de données et de voir si cela est correct.