J'ai une grande table (plus de 10 millions d'enregistrements). cette table est fortement utilisée pour la recherche dans l'application. Donc, j'ai dû créer des index sur la table. Cependant, je rencontre une performance lente lorsqu'un enregistrement est inséré ou mis à jour dans la table. Ceci est probablement dû au recalcul des index.indexation d'une grande table dans SQL SERVER
Y at-il un moyen d'améliorer cela.
Merci à l'avance
Vous pouvez essayer de réduire le nombre de divisions de page (dans vos index) en réduisant le facteur de remplissage de vos index. Par défaut, le facteur de remplissage est 0 (identique à 100%). Ainsi, lorsque vous reconstruisez vos index, les pages sont complètement remplies. Cela fonctionne très bien pour les tables qui ne sont pas modifiées (insertion/mise à jour/suppression). Cependant, lorsque les données sont modifiées, les index doivent changer. Avec un facteur de remplissage de 0, vous êtes assuré d'obtenir des fractionnements de page. En modifiant le facteur de remplissage, vous devriez obtenir de meilleures performances sur les insertions et les mises à jour, car la page ne devra PAS TOUJOURS être divisée. Je vous recommande de reconstruire vos index avec un facteur de remplissage = 90. Cela laissera 10% de la page vide, ce qui entraînerait moins de divisions de page et donc moins d'E/S.Il est possible que 90 ne soit pas la valeur optimale à utiliser, donc il peut y avoir quelques essais et erreurs impliqués ici. En utilisant une valeur différente pour le facteur de remplissage, vos requêtes de sélection peuvent devenir légèrement plus lentes, mais avec un facteur de remplissage de 90%, vous ne le remarquerez probablement pas trop.
Nous avions besoin de voir vos index, mais probablement oui.
Certaines choses à garder à l'esprit sont que vous ne voulez pas simplement mettre un index sur chaque colonne, et vous ne voulez généralement pas une seule colonne par index. La meilleure chose à faire est de savoir si vous pouvez enregistrer des recherches réelles, suivre ce que les utilisateurs recherchent réellement et créer des index ciblés sur ces types de recherches spécifiques.
C'est une ingénierie classique compromis ... vous pouvez faire la pelle plus légère ou plus forte, jamais les deux ... (jusqu'à ce qu'une percée dans la science des matériaux.)
Plus indice signifie plus d'entretien de DML, des moyens requêtes plus rapides. Moins d'index signifie moins de maintenance DML, ce qui signifie des requêtes plus lentes.
Il se peut que certains de vos index soient redondants et puissent être combinés. En plus de ce que Joel a écrit, vous devez également définir le SLA pour DML. Est-ce que c'est bon que ça soit plus lent, vous avez remarqué que ça a ralenti mais est-ce vraiment important par rapport à l'amélioration de la requête que vous avez obtenue ... OK, est-ce correct d'avoir une pelle légère aussi faible?
Il y a un certain nombre de solutions que vous pourriez choisir
a) Vous pouvez partitionner la table
b) Envisager d'effectuer des mises à jour par lots à des heures creuses (comme la nuit)
c) Depuis l'ingénierie est un compromis entre les compromis, vous devez choisir lequel est le plus important (Sélectionner ou Mettre à jour/insérer/supprimer) et quelle opération est la plus importante. En supposant que vous n'avez pas besoin des résultats en temps réel pour un « insert », vous pouvez utiliser un courtier de service de serveur Sql pour les opérations à effectuer le « moins important » le fonctionnement de façon asynchrone
http://msdn.microsoft.com/en-us/library/ms166043(SQL.90).aspx
Merci -RVZ
Si vous avez un index cluster qui n'est pas dans un champ numérique d'identité, réorganiser les pages peut vous ralentir. Si c'est le cas, voyez si vous pouvez améliorer la vitesse en en faisant un index non cluster (plus rapide qu'aucun index mais plutôt plus lent que l'index clusterisé, donc vos sélections peuvent ralentir mais les insertions s'améliorent)
J'ai trouvé des utilisateurs plus disposés à tolérer une insertion légèrement plus lente ou une mise à jour à une sélection plus lente. C'est une règle générale, mais si elle devient inacceptable (ou pire), personne ne peut s'en occuper aussi bien.
BTW, 10M lignes n'est plus grand. Peut-être que dans MSAccess, SQL Server ne devrait pas avoir de problème avec cela. –