Indexes on Andy M Mallon - AM²

Not all stats should be auto-updated

Thu, 29 Aug 2024 11:19:07 -0400

Statistics auto-updates are generally a good thing–auto-update of statistics is the default behavior in SQL Server. Having the freshest information about the data “shape” helps to inform the best selection of an execution plan for queries.

Except for when it doesn’t.

Because It Depends™️

Let’s talk about the trade-offs.

What's the use case of disabling an index?

Sun, 25 Sep 2022 17:10:28 -0400

Question

I just learned that indexes can be disabled on a table. Even the clustered index can be disabled. After that, users can’t access the index or the data if clustered index. When will we disable an index? I just don’t understand the use case.

Making non-SARGable queries seek, without changing the query

Wed, 06 May 2020 08:36:27 -0400

We’ve all been there. You’ve got a query where the JOIN or WHERE predicate is not SARGable. You’ve read about how this can be a problem, and how bad it is for performance.

Alas, you cannot change the query. Sometimes this reason is political, sometimes it’s because you’ve got a third-party app and simply don’t have access to the code. But you do have access to the database…

When to put a non-clustered index on your clustering key

Tue, 03 Sep 2019 21:17:14 -0400

These vines are clustered by Cabernet Sauvignon. #### First off, let's remember the difference between clustered & nonclustered indexes

The clustered index is organized by the key columns. It also includes every other column as part of the row structure (ie, it has the entire row).

Nonclustered index storage on clustered columnstore

Fri, 06 Jan 2017 11:47:02 -0500

Question

In SQL Server, a non-unique nonclustered index on a rowstore table incorporates the base object’s bookmark (RID or clustering key) at all levels of the nonclustered index structure. The bookmark is stored as part of the nonclustered index key at all index levels.

Does it ever make sense to have a clustered and non clustered index for the same column

Tue, 16 Aug 2016 22:08:55 -0400

Question

Does it ever make sense to have a clustered and non clustered index for the same column

I inherited a database and a web service that goes with it.

Looking at the indexes for duplicates I see an two indexes that point at the same column (1 column and sorted the same way). One is clustered and one is not, that is the only difference I see.

Data Compression: How page compression works

Mon, 22 Feb 2016 10:00:59 -0500

SQL Server supports two kinds of data compression on rowstore data. Columnstore compression is for a different day. You can compress heaps, clustered indexes (on both tables and views), and nonclustered indexes (on both tables and views).

Compression requirements

Data compression is available in SQL Server 2008 & newer. It was introduced as an Enterprise Edition feature–if you were using Standard Edition or Express, then you were out of luck. Starting with SQL Server 2016 SP1 (thus all currently-supported versions), data compression is available across all Editions. There are benefits & costs to using data compression–as with anything, make sure you understand it before you implement it.

Data Compression: How row compression works

Mon, 15 Feb 2016 10:07:29 -0500

Compression requirements

Data compression is available in SQL Server 2008 & newer. It is an Enterprise Edition feature–if you’re using Standard Edition or Express, then you’re out of luck. There are benefits & costs to using data compression–as with anything, make sure you understand it before you implement it.

Data Compression: Costs & benefits

Tue, 29 Dec 2015 15:00:56 -0500

Compression requirements

Data compression is available in SQL Server 2008 & newer. It is an Enterprise Edition feature–if you’re using Standard Edition or Express, then you’re out of luck.

sp_get_basetable_list

Thu, 22 May 2014 15:18:00 -0400

At work, we make extensive use of views & synonyms. The reasons are complex (and fodder for another post), but here’s a simplified example:

Pricing data is updated multiple times per day, and we want to keep multiple generations of the pricing table online. By pointing the synonym to the latest pricing table, we can redirect users to the current/correct data. If there's a problem, we can "roll back" the latest pricing updates by simply pointing the synonym back to the prior generation of pricing data.

Obviously, this can create some confusion when you do need to find the actual table (eg, to see indexes, or to update data). What pricing table is the real pricing table? Sure– you can query system views to find out the real table(s) referenced by the synonym or view. When you do this hundreds (or thousands) of times, it can really add up. Time to automate.