Quelle est la probabilité que la fragmentation d'une table avec 40000 produits affecte les performances
L'administration de la base de données n'est donc pas un de mes points forts, j'ai donc quelques questions.
Tout cela concerne les performances d'un site Web que je consulte et j'ai passé pas mal de temps à rechercher/diagnostiquer.
- Il y a deux sites, un site de test et un site en direct.
J'ai remarqué que les temps de chargement des pages sont beaucoup plus longs sur le site en direct que sur le site de test.
Les spécifications du site de test sont vraiment faibles - Processeurs virtuels VPS 2 avec 14 Go RAM et site Web SQL + fonctionnant sur le même VPS
Les spécifications du site Web en direct sont de 4 serveurs dédiés, tous avec 8 processeurs virtuels et 16 Go de RAM
Le site en direct utilise un serveur dédié distinct pour SQL avec 16 processeurs virtuels et 112 Go de RAM
Le site Web compte en moyenne 120 utilisateurs simultanés en moyenne à tout moment, mais peut varier de 70 à 150 et lorsque nous envoyons une campagne par e-mail, il peut atteindre 400. Lorsque nous atteignons 400, le processeur comme vous vous en doutez peut atteindre 100% selon les actions des utilisateurs font sur le site Web, mais ils tiennent assez bien la même chose avec la RAM.
Je m'attendrais à ce que le site Web en direct fonctionne réellement plus rapidement que le site Web de test, mais ce n'est pas le cas. J'ai parcouru le code mais je crois fermement que cela est dû à la base de données. La taille de la base de données du site Web en direct est supérieure à 50 Go lors de la sauvegarde, et le site de test est de 4 Go.
Les deux bases de données sont assez fragmentées et je me demande dans quelle mesure la fragmentation affectera les performances?
De plus, comme le site Web en direct est plusieurs fois plus grand que le site de test, une fragmentation élevée affectera-t-elle beaucoup plus les performances du site en ligne que le site de test?
Voici une capture de l'un des index de la table des produits. 
Parce que je n'ai jamais traité de cela auparavant, voici quelques conseils sur la reconstruction/l'actualisation des index.
Dois-je mettre le site Web en mode maintenance afin que personne ne puisse interagir avec les tables pendant que je reconstruis/actualise les index?
Combien de temps cela prendrait-il sur une table avec 12 index et 40000 produits?
Merci
Sur la base des données que vous avez fournies -
il y a 67 pages au total. La fragmentation d'index pour une si petite table n'affecterait pas les performances. Je ne m'inquiéterais pas de la fragmentation d'index pour la table que vous avez mentionnée.
Vous devez mettre à jour vos statistiques de table afin que le serveur SQL puisse générer un meilleur plan de requête.
Je commencerais mon dépannage par
- En cours d'exécution sp_Blitz: bilan de santé général
Lire: Arrêtez de vous soucier de la fragmentation de SQL Server
Les indices sont tenus de se fragmenter en cours d'utilisation (temps). Ce qui importe, c'est si cela affecte les performances.
Habituellement, nous ne nous soucions pas des indices avec page_count <500. (Nous comme dans mon équipe) Cependant, il n'y a pas de règle stricte pour un page_count particulier. Dans ma boutique précédente, nous avions fixé la limite dans notre script Ola pour 1000 nombre de pages. Mais oui avec un index ayant page_count = 67, la fragmentation sera toujours du côté supérieur.
Vous ne devez pas vous inquiéter de la fragmentation du nombre de pages actuel.
Veuillez essayer le blog ci-dessous de Paul Randal:
D'où viennent les seuils de fragmentation de l'index Books Online?
La principale différence entre votre serveur de test et votre serveur Live est Concurrency.
Vous n'avez pas fait Concurrency Test dans votre serveur de test.
Concurrency est l'une des principales raisons pour lesquelles Live Site est lent.
Quel code est écrit dans l'application frontale comme ce que vous avez écrit dans la chaîne de connexion. Comme connection pool, si connection est correctement close après chaque transaction. C'est souvent la principale raison de la lenteur.
Ensuite, votre autre partie du code frontal.
Quelle requête est écrite dans votre SP. Que ce soit deadlock problème en raison de l'utilisateur simultané.
Existe-t-il une situation où un utilisateur simultané tente de mettre à jour le même ensemble de lignes? Comment avez-vous géré la condition de course?
Pourquoi il y a 12 index dans une seule table avec seulement 40000 enregistrements?
Veuillez jeter la structure de la table avec tous les index.