Home/ Questions/Q 3421302
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-18T06:05:33+00:00

In the system I’m working on, we were seeing a particular SELECT use a

  • 0

In the system I’m working on, we were seeing a particular SELECT use a clustered index scan, instead of using the index which was created for this SELECT. I took a look at the statistics for the index, and found that they were 26 days old. I updated the statistics with FULLSCAN. Now the SELECT is using the index.

AUTO_UPDATE_STATISTICS has been enabled in this database the entire time. Why did the statistics not get updated?

Looking at the STATS_DATE() output (query below):

SELECT 
    object_name = Object_Name(ind.object_id),
    IndexName = ind.name,
    StatisticsDate = STATS_DATE(ind.object_id, ind.index_id),
    ind.type
  FROM SYS.INDEXES ind
  order by STATS_DATE(ind.object_id, ind.index_id) desc

I see that many indexes were updated recently. Some large tables which have data updates every day have not had updated statistics in weeks.

How does MSSQL 2005 decide when to update statistics when AUTO_UPDATE_STATISTICS is enabled? The documentation states:

A statistics update is initiated whenever the statistics used in a query execution plan fail a test for current statistics. . . Almost always, statistical information is updated when approximately 20 percent of the data rows has changed.

Can this be trusted? Perhaps these tables are so large that the “current statistics test” is passing even though records are being inserted on a daily basis.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Here’s a link to the algorithm details in a Microsoft whitepaper

    http://technet.microsoft.com/sv-se/library/cc966419(en-us).aspx#XSLTsection130121120120

    And this quoted from Erland Sommarskog:

    When you have an empty table,
    autostats first kicks in after 500
    rows. From there, autostats sets in
    when 20% of the rows have been
    modified. This is measure from some
    rowmodctr.

    This has the effect that big tables
    with a monotonously growing key where
    queries goes against the trunk have
    their statistics updated far too
    rarely.

    Whereas small tables where all rows
    are updated frequently, or where or
    rows are added and deleted, have their
    stats updated very often, which may
    cause recompilation issues.

    • 0