Ich mache heute einige SQL-Tuning und finde einen seltsamen SQL während des Tests:
%Vor%Sieht so aus, dass es einige SQL-Server-Indizes "neu indexiert" oder "neu erstellt". Aber meine Frage ist, wie können wir das während des langen Belastungstests vermeiden, abgesehen von "Neuindizierung" für jede Tabelle vor dem Test.
Und diese SQL wird 16862ms verbrauchen, weil meine Tabelle genügend Zeilen enthält. Und es gibt viele einfügen Aktion in meinem Test.
Dies scheint von der Aktualisierung von Statistiken zu sein.
Erfolgt die Aktualisierung von Statistiken in einer normalen Produktionsumgebung? Wenn ja, sollte ein Lasttest, um eine Produktionsumgebung widerzuspiegeln, auch Statistiken aktualisieren?
Um die Option AUTO_UPDATE_STATISTICS zu deaktivieren, verwenden Sie sp_autostats für die gewünschten Tabellen (siehe Ссылка ).
Bevor ich irgendetwas ändere, lasse ich es so laufen, wie es ist, mit SQL Profiler und dann Tuning Advisor, um die Ergebnisse zu analysieren. Es kann einige Ineffizienzen in der Tischkonstruktion finden. Auch einige ziemlich unschuldige Dinge können es beeinflussen: z.B. "zu viele Indizes" haben oder GUID als PK für eine Tabelle verwenden, die mehr Einfügungen als Auswahlwerte enthält ...
Wenn alle Ineffizienzen behoben sind und du immer noch einen Leistungseinbruch hast, dann kannst du die Auto-Statistik ausschalten und die Statistiken außerhalb der Spitzenzeiten aktualisieren lassen. Aber dann musst du das gleiche bei der Produktion tun, wie es die Person zuvor gesagt hat.
Tags und Links sql sql-server testing performance