Sql Server int vs nvarchar comparaison sur les performances?

Question

Pour vos gourous de conception de base de données/performances là-bas.

Je suis en train de concevoir une table, j'ai le choix entre utiliser int ou nvarchar (128) pour une colonne, supposer que l'espace n'est pas un problème. Ma question est ce qui donnera la performance

quand je recherche avec colonne int

where ID = 12324

ou quand je recherche avec colonne nvarchar (la clé est la valeur entière, donc je ne suis pas en utilisant l'opérateur LIKE)

where Key = 'my str'

Je suis sûr que pour les petits ensembles de données, il n'a pas d'importance, mais supposons que ces données seront dans les millions de lignes.

Answer 1

INT sera plus rapide - voici pourquoi:

• SQL Server organise ses données et ses index dans les pages de 8K
• si vous avez une page d'index avec la touche INT, vous obtenez à peu près 2'000 INT entries
• si vous avez NVARCHAR (128) et que vous utilisez en moyenne 20 caractères, qui est de 40 octets par entrée, soit environ 200 entrées par page

donc, pour la même quantité d'entrées d'index, le NVARCHAR (128) ca se utiliserait dix fois plus de pages d'index.

Le chargement et la recherche de ces pages d'index entraîneront beaucoup plus d'opérations d'E/S. Donc, pour faire court: si vous le pouvez, utilisez toujours INT.

Answer 2

Le principal problème avec les performances avec ceci est la taille du champ - un int est de 4 octets, tandis qu'un nvarchar(128) sera de 254 octets. Tout cela doit être géré par le serveur SQL, donc gérer un int sera beaucoup plus rapide qu'un nvarchar(128).

Answer 3

L'espace est toujours un problème dans les bases de données. Les clés plus larges signifient moins d'entrées par page, plus de pages numérisées pour agréger et additionner des valeurs, signifie plus d'entrées/sorties, moins de performances. Pour les index clusterisés, ce problème est multiplié par chaque index non cluster, car ils doivent reproduire la clé de recherche (clé groupée) dans leurs feuilles. Donc, une clé de type nvarchar(128) sera presque toujours être pire qu'un INT. Par contre, n'utilisez pas une touche INT si elle n'est pas appropriée. Par contre, n'utilisez pas une touche INT. Utilisez toujours la clé appropriée, en fonction de vos requêtes. Si vous allez toujours interroger par une valeur de colonne nvarchar (128), alors peut-être un bon candidat clé en cluster. Si vous allez agréger par la clé nvarchar (128), alors probablement un bon candidat clé en cluster.

Answer 4

Je voudrais utiliser l'int pour les performances (si cela va avoir des jointures en particulier) et mettre un index unique sur la clé naturelle potentielle pour l'intégrité des données.