Slim mais à long SQL Server 2005 Tableau

Question

J'ai une table SQL avec la structure suivante:

Code1 - int 
Code2 - int 
Val1 - real 
Val2 - real 
Val3 - real 

Il n'y a qu'un seul index (cluster) étaient Code1 est la première colonne indexée et Code2 est le deuxième. La taille d'un seul enregistrement est de 20 octets.

Je dois être en mesure de stocker environ 150 000 000 enregistrements et la plus grande opération de sélection porterait sur 500 000 enregistrements. Je suppose que la taille de la table sera autour de 3GB

Je voudrais savoir si cette conception fonctionnera ou il pourrait y avoir des problèmes 'inexpliqués' ou des ralentissements en traitant avec une telle grande table.

Answer 1

Il y a une question très complète sur les performances de SQL et de grandes tables: Very large tables in SQL Server

Answer 2

Fondamentalement, une table avec 150 millions de lignes est rien pour SQL Server - va même pas casser une vraie sueur :-)

Le point est vraiment: comment accéder aux données? Quel genre de requêtes aurez-vous? Par exemple. Si vous avez des requêtes qui ont une clause WHERE avec seulement la colonne "col2", alors vous n'avez pas une bonne configuration avec un index clusterisé sur (col1, col2).

En outre: comment les données sont-elles distribuées dans vos champs? Lesquels sont sélectifs, lesquels sont plus uniformes? Si col1 ou col2 sont hautement sélectifs (par exemple, une seule valeur sélectionne significativement moins de 2% des données), utilisez ce champ pour vos sélections, si possible. Indexer quelque chose comme un champ "genre" qui pourrait avoir deux, trois valeurs différentes n'aidera pas vraiment, puisque toute sélection utilisant ce champ comme une clause WHERE retournera toujours trop de données pour être efficace.