Timeline for Rebuilding fragmented indexes on SQL Server
Current License: CC BY-SA 3.0
3 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Dec 7, 2017 at 12:32 | comment | added | John K. N. | The statistics are one of the bases for the query optiimzer to determine which query plan to use (or build) and albeit which index to use. If the statistics don't contain the correct (or contain the outdated) distribution of the items (index or column), then how can the right query plan be chosen? We had a application with 4 base tables containing 1 to 20 Mio records each, with quite a lot of indexes. Data was entered at approx. 20'000 rows/day for the main table. We had to update the statistics for the 4 base tables once a day to keep the application at peak performance. | |
| Dec 7, 2017 at 12:07 | comment | added | Matt Roberts | Wow thanks, lot's to go on here. We have had an issue actually where a bad query plan has been chosen, which is one reason for me to keep re-indexeing the tables. but as you said - this might be more of an issue about the statistics than index fragmentation.... | |
| Dec 6, 2017 at 9:11 | history | answered | John K. N. | CC BY-SA 3.0 |