Friday, April 19, 2024
HomeHow ToSQL Server Index Fragmentation In-depth

SQL Server Index Fragmentation In-depth

There is no way to completely avoid index fragmentation in any SQL Server environment. It does not depend on your SQL Server version, the I/O subsystem you have, or your hardware. In this article, we will drill down into the SQL Server index fragmentation issue and how to tackle it. We will figure out why index fragmentation is a problem and how it affects overall performance and discuss how to detect and avoid it.

This article has been updated on Oct/06/2023. We have added some useful information on best practices to prevent index fragmentation, optimizing performance through fill factor utilization, highlighting new features and updates in recent SQL Server versions, and strategies for minimizing index fragmentation.


What is index fragmentation?

We are going to begin with defining index fragmentation. It is a common term that describes numerous effects that can occur because of data modifications. Chances are, you already know that SQL Server stores data on 8KB data pages. Eight contiguous pages form the extent. A data page, both in clustered or non-clustered indexes, contains pointers to the next and previous pages. The following picture demonstrates that there is no fragmentation.

No fragmentation

Let’s insert a new row into the index and see what happens. SQL Server inserts a new row on the data page in case there is enough free space on that page. Otherwise, the following happens:

  1. SQL Server allocates a new data page or even a new extent.
  2. A part of data from the existing (old) data page transfers to a newly allocated data page.
  3. In order to keep the logical sorting order in the index, pointers on both pages are updated.
Logical and internal fragmentation

As a consequence, we have two types of index fragmentation:

Logical fragmentation (also called external fragmentation or extent fragmentation) — the logical order of the pages does not correspond to their physical order. As a result, SQL Server increases the number of physical (random) reads from the hard drive, making the read-ahead mechanism less efficient. This directly impacts the query execution time because random reading from the hard drive is far less efficient compared to sequential reading.

Internal fragmentation — the data pages in the index contain free space. This leads to an increase in the number of logical reads during the query execution because the index utilizes more data pages to store data.

The fragmentation of a SQL Server database can significantly impact its performance. It leads to increased disk I/O operations and slower query response times as the server must sift through scattered data. Moreover, it can cause decreased efficiency in memory usage and even contribute to higher storage costs due to suboptimal space utilization.

Detecting index fragmentation

Using SQL commands

Before you decide which defragmentation approach to use, it is required to analyze the index to find out the degree of fragmentation. You can use the sys.dm_db_index_physical_stats data management function to analyze fragmentation. The following columns in the resultset are the most important:

avg_page_space_used_in_percenat shows the average percentage of the data storage space used on the page. This value allows you to see the internal index fragmentation.

avg_fragmentation_in_percent provides you with information about external index fragmentation. For tables with clustered indexes, it indicates the percent of out-of-order pages when the next physical page allocated in the index is different from the page referenced by the next-page pointer of the current page. For heap tables, it indicates the percent of out-of-order extents when extents are not residing continuously in data files.

fragment_count indicates how many continuous data fragments the index has. Every fragment constitutes a group of extents adjacent to each other. Adjacent data increases the chances that SQL Server will use sequential I/O and Read-Ahead while accessing the data.

Using SQL Server Management Studio (SSMS)

In case you are a SQL Server Management Studio (SSMS) user, the approach to detecting fragmentation will be a bit different:

  1. Launch SSMS and connect to the SQL Server instance containing the database you want to analyze.
  2. Expand the Databases node in the Object Explorer.
  3. Right-click the database you are interested in and select New Query.
  4. In the query window that opens, type DBCC SHOWCONTIG ('table_name'); replacing table_name with the name of the table you wish to analyze. Click Execute or press F5.
  5. The results will display information about the fragmentation level of the indexes on the specified table. Look for the Scan Density and Logical Scan Fragmentation columns to assess the degree of fragmentation. Based on the output, you can determine whether index maintenance is needed.

Advanced tools and functions for analysis

While default tools within SQL Server can effectively address index fragmentation, there are instances where more advanced solutions become necessary, especially for ongoing maintenance. This is where dbForge Index Manager proves invaluable. Its specialized features and capabilities streamline the process of identifying and managing fragmented indexes, ensuring optimal database performance. With this tool, database administrators gain a powerful tool that simplifies the often complex task of maintaining index health, ultimately leading to smoother and more efficient database operations.

To open the Index Manager in SSMS, right-click the database you want to analyze and select Index Manager > Manage Index Fragmentation. This will trigger the database scanning.

After scanning the database, the Index Manager: [database_name] document opens, dividing all the indexes into two sections:

  • Action required: This section displays all indexes that require maintenance based on the default index fragmentation analysis criteria.
  • No action required: This section displays indexes that do not require maintenance based on the default index fragmentation analysis criteria.

Each section displays the following index details:

  • Fix type, which is a recommended action to take on the indexes
  • Index name
  • Database object name to which the index belongs
  • Type of the index, either clustered or non-clustered
  • Index size in pages and Mb
  • Index fragmentation in %
  • Partition number
  • Rows in partition
  • Reason for index maintenance
  • Result of the fix action. When you click Fix, this column will inform you that the index has been successfully rebuilt or reorganized (depending on the fix type)

In the Action required section, you can perform the actions on all indexes by selecting the checkbox next to the section name or individual indexes by selecting the checkbox next to the specific index on the results grid.

How index fragmentation occurs?

In order to avoid or at least minimize the index fragmentation, we need to figure out why it occurs in the first place:

  1. Data modifications and fragmentation: When data is modified, such as through inserts, updates, or deletes, the index structure can become disorganized. This happens because the database engine may not always be able to keep the index perfectly ordered, leading to fragmentation over time.
  2. Page splits and extents: Page splits occur when a new record is added to a page that’s already full. This forces the page to split into two, causing fragmentation. Extents, which are groups of eight contiguous pages, can also contribute to fragmentation if they become unevenly distributed.
  3. Examples and real-world cases of fragmentation: Understanding specific examples and real-world cases of fragmentation provides insight into its impact. For instance, a table that experiences frequent inserts and deletes without regular maintenance can exhibit high levels of fragmentation. This can lead to slower query performance and increased disk I/O operations.

Best practices to avoid index fragmentation

To avoid index fragmentation, try to adhere to the following rules:

  1. Choose a cluster key that complements the table’s insert pattern
  2. Do not insert records with random key values
  3. Do not update records to make them longer
  4. Do not update index key columns
  5. Be aware of features that can cause page splits
  6. Implement index fill factors

Leveraging fill factor for optimal performance

Utilizing index fill factor

Set SQL Server to leave free space on index leaf pages. The main idea is to allow records to expand and records to be inserted without filling out the page and having to cause page split.

Therefore, you need to figure out how much space you want to leave. The amount of space to use is 100% minus the fill factor value (e.g., a fill factor of 70 means 30% free space).

SQL Server only uses the fill factor when an index is created, rebuilt, or reorganized. The index fill factor is not used during regular inserts, updates, and deletes. In fact, that does not make any sense because the whole point is to allow inserts and updates to happen and to add more records without filling up the page.

It is possible to set the instance fill factor using sp_configure, but it is not recommended. The reason is when you set the fill factor for the entire instance, there are probably some indexes that do not need a fill factor. If you find that you’ve got fragmentation problems on the non-leaf level of the index (rare), you can use the PAD_INDEX option. It takes the fill factor that has been specified and puts it up to the non-leaf level.

Setting a fill factor

Probably the easiest way to set the fill factor is to use the FILLFACTOR option when you create or rebuild an index. You can also use the Object Explorer to set the fill factor. Note that you can not set the fill factor when you reorganize an index. Both REBUILD and REORGANIZE use the fill factor stored in index metadata. Otherwise, they use the instance-wide (default) fill factor unless the FILLFACTOR option is specified for a REBUILD.

An obvious question arises: “What fill factor do I use?”. Well, actually, there is no magic number. You just need to pick an initial fill factor and implement it. Put it into production and then monitor how quickly fragmentation occurs. Then, choose to do one or both of the following: increase/decrease the fill factor or change the frequency of index maintenance.

New features and updates in recent SQL Server versions

Understanding how the most recent SQL Server updates affect index fragmentation is crucial for database administrators and developers. It enables them to adapt their maintenance strategies to ensure optimal performance in the evolving SQL Server environment. New features can impact index fragmentation in several ways:

Feature Purpose
SQL Server ledger Ledger provides a tamper-proof record of transactions, potentially reducing the need for extensive indexing by ensuring data integrity and reliability.
Support for more memory Increased memory support allows for larger in-memory tables and indexes, lowering disk I/O and mitigating fragmentation.
Concurrency scalability support Enhanced concurrency management can lead to more efficient transaction processing, reducing contention that can contribute to fragmentation.
Data virtualization for any data lake Virtualization capabilities can streamline data access, reduce the need for extensive indexing, and minimize fragmentation.
Query Store by default and replica support Query Store allows for the tracking of query performance over time. It can indirectly reduce fragmentation by identifying and optimizing poorly performing queries.

Strategies for removing index fragmentation

Let’s figure out what is the difference between ALTER INDEX … REBUILD and ALTER INDEX … REORGANIZE. The following table demonstrates the difference:

No knowledge of schema requiredNo knowledge of schema required
Can operate on single partitionCan operate on single partition
Possible to determine Progresssys.dm_exec_requests
Can use multiple CPUsAlways single-threaded
Updates index statistics No statistics update
Faster for a heavily-fragmented indexSlower for a heavily-fragmented index
Lots of optionsVery few options
Can set the index FILLFACTORCannot set the index FILLFACTOR
Can reduce logging by switching to the BULK_LOGGED recovery modeAlways fully logged
Choose online or offline Always online
Offline requires the SCH_M table lock Only requires the IX table lock
Must build a new index before dropping and old one Only requires 8KB of disk space as existing pages are shuffled in place
Slower for a lightly fragmented index Faster for a lightly fragmented index
All-or-nothingInterruptible with no loss of work
Does not operate on LOB dataCompacts LOB data by default

There is no correct answer in regards: “What to use: REBUILD or REORGANIZE?” One of Microsoft Books Online provides the following guidance:

0 to 5-10% — do nothing

5-10% to 30% — do REORGANIZE

30% to 100% — do REBUILD

Eventually, you have several basic options to remove index fragmentation:

  1. Choose to rebuild the index
  2. Choose to reorganize the index
  3. Be forced to reorganize by HA/DR features
  4. Do nothing
  5. Use CREATE INDEX…WITH (DROP_EXISTING=ON) — does the same as ALTER INDEX…REBUILD, but you need to specify the entire CREATE INDEX statement.


In conclusion, understanding and addressing index fragmentation is crucial for maintaining a high-performing SQL Server database. By learning how it occurs, detecting it effectively, and implementing best practices such as leveraging fill factor and staying updated with the latest features, you can proactively manage and mitigate fragmentation issues. Additionally, employing effective strategies for removing fragmentation ensures your database continues to operate at its optimal efficiency. By following these guidelines, you can enhance the overall performance and longevity of your SQL Server environment.

In case you need a tool that allows you to quickly collect index fragmentation statistics and detect databases that require maintenance, we might offer just the one. With dbForge Index Manager, you can instantly rebuild and reorganize SQL Server indexes in visual mode or generate SQL scripts for future use. Give it a go with its fully functional 30-day free trial.

Useful links