Pour votre conception de la base de données / GURUS de performance sur la base de données.
Je concevons une table, j'ai le choix d'utiliser Int ou Nvarchar (128) pour une colonne, suppose que l'espace n'est pas un problème. Ma question est qui donnera des performances
Quand je cherche avec la colonne INT
ou lorsque je recherche avec la colonne Nvarparar (la clé est la valeur entière, donc je n'utilise pas comme opérateur)
Je suis sûr que des jeux de données plus petits, cela n'a pas d'importance, mais supposons que ces données seront dans les millions de lignes. où id = 12324
où la clé = 'mon str'
4 Réponses :
Le problème principal avec la performance avec c'est la taille du champ - un Tout cela doit réussir par SQL Server, la gestion d'un int est de 4 octets, alors qu'un nvarchar (128) sera de 254 octets.
int sera beaucoup plus rapide qu'un NvarchaRar (128) .
+1 Bon point. De plus, il y a un peu moins de travail pour obtenir une CPU pour traiter un INT plutôt que d'une chaîne. Avec des millions de lignes, cela pourrait entraîner une différence non négligeable. Je serais intéressé de voir des tests de performance réels à ce sujet.
espace est toujours un problème dans les bases de données. Les touches plus larges signifient moins d'entrées par page, plus de pages numérisées à des valeurs agrégées et de somme, signifie plus d'IO, moins de performances. Pour les index en cluster, ce problème est multiplié par chaque indice non en cluster, car ils doivent reproduire la clé de recherche (clé en cluster) dans leurs feuilles. Donc, une clé de type D'autre part, n'utilisez pas une clé INT si cela n'est pas approprié. Utilisez toujours la clé appropriée, envisager vos requêtes . Si vous allez toujours interroger par une valeur de colonne Nvarparar (128), alors éventuellement un bon candidat clé en cluster. Si vous allez Agrégate par la clé Nvarchar (128), alors probablement un bon candidat clé en cluster. nvarchaar (128) presque est toujours pire qu'un int.
+1: naturel> clés artificielles, mais il y a très peu de clés naturelles IME.
int sera plus rapide - voici pourquoi:
Donc, pour la même quantité d'entrées d'index, l'affaire Nvarparar (128) utiliserait dix fois plus de pages d'index.
Chargement et recherche de ces pages d'index engendrera de manière significative plus d'opérations d'E / S.
Donc, pour rendre les choses courtes: si vous le pouvez, utilisez toujours INT.
J'utiliserais l'INT pour la performance (si cela va avoir des jointures surtout) et mettre un indice unique sur la clé naturelle potentielle pour l'intégrité des données.