Existe-t-il des raisons de performances pour utiliser des puissances de deux pour les tailles de champs dans ma base de données?

Question

Il y a longtemps, quand j'étais un jeune lat, je faisais beaucoup de programmation d'assembleur et d'optimisation. Aujourd'hui, je me retrouve principalement à construire des applications web (ça va aussi ...). Cependant, chaque fois que je crée des champs pour des tables de base de données, je trouve des valeurs comme 16, 32 & 128 pour les champs de texte et j'essaie de combiner des valeurs booléennes dans des champs de données SET.

Est-ce que donner un champ de texte d'une longueur de 9 va rendre ma base de données plus lente à long terme et est-ce que je l'aide en spécifiant une longueur de champ plus facile à aligner?

Answer 1

L'optimisation de la base de données est très différente de l'optimisation du code machine. Avec les bases de données, la plupart du temps vous voulez réduire les E/S de disque, et en essayant d'aligner les champs de manière inutile, vous réduirez le nombre d'enregistrements dans un bloc/une page de disque. En outre, si un alignement est bénéfique, le moteur de base de données le fera automatiquement pour vous.

Ce qui compte le plus, ce sont les index et la façon dont vous les utilisez. Essayer des astuces pour emballer plus d'informations dans moins d'espace peut facilement finir par rendre plus difficile d'avoir de bons index. (N'en faites pas trop, cependant, non seulement les index ralentissent les INSERTs et les UPDATEs vers les colonnes indexées, mais cela signifie aussi plus de travail pour le planificateur qui doit considérer toutes les possibilités.) essayez de l'utiliser sur vos sélections (en particulier, celles avec plus d'une table) pour avoir une idée de la façon dont le moteur de base de données fera son travail.

Answer 2

La taille du champ lui-même peut être importante, mais généralement pour le texte si vous utilisez nvarchar ou varchar ce n'est pas un gros problème. Puisque la DB prendra ce que vous utilisez. le suivant aura un plus grand impact sur votre vitesse de SQL:

n'ont pas plus de colonnes alors vous avez besoin. plus grande table en termes de colonnes signifie que la base de données sera moins susceptible de trouver les résultats de vos requêtes sur la même page de disque. Notez que ceci est vrai même si vous ne demandez que 2 colonnes sur 10 dans votre sélection ... (il y a une façon de combattre cela, avec des index clusterisés mais cela ne peut concerner qu'un scénario limité).

Vous devriez donner plus de détails sur les types de problèmes de conception/alternatives que vous envisagez d'obtenir des conseils supplémentaires.

Answer 3

Quelque chose qui est implicite ci-dessus, mais qui peut être rendu explicite. Vous n'avez aucun moyen de savoir ce que l'ordinateur est en train de faire. Ce n'est pas comme au bon vieux temps où vous pouviez regarder l'assembleur et savoir très bien quelles étapes le programme va prendre. Une valeur qui "ressemble" à celle d'un registre CPU peut en fait être récupérée à partir d'un cache sur la puce ou même à partir du disque. Si vous n'écrivez pas en assembleur mais en utilisant un compilateur optimisant, ou plus sûrement, le bytecode sur un moteur d'exécution (Java, C#), abandonnez l'espoir. Ou abandonner l'inquiétude, ce qui est la meilleure idée.

Il faudra probablement des milliers, peut-être des dizaines de milliers de cycles machine pour écrire ou récupérer cette valeur de base de données. Ne vous inquiétez pas des 10 cycles supplémentaires dus aux alignements de mots complets.