Home/ Questions/Q 7883159
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-03T04:27:35+00:00

Lets assume a table like this [KEY] [int] NOT NULL, [INT1] [int] NULL, [INT2]

  • 0

Lets assume a table like this

[KEY] [int] NOT NULL,
[INT1] [int] NULL,
[INT2] [int] NULL,
[INT3] [int] NULL,
[STR1] [varchar](20) NULL,
[STR2] [varchar](20) NULL,
[STR3] [varchar](20) NULL,

The query is very flexed but always like this format:
SELECT KEY FROM [TABLE] WHERE...

The search condition few times on single column, and most time on several columns, for [int] type, quesy as BETWEEN or >= or <=, for varchar, always query as = or IN []. All conditions connect with AND

Since the query is not always fixed on same column(s), so I wonder, if I create INDEX on every single column, will it increase performance, or just waste at all.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Don’t just create an index on every single column – that’s a total waste of time and resources!

    Basically, my approach is always:

    1. define a good primary and clustering key on any “normal” table (except for e.g. staging tables etc.) – that’s a big step already

    2. put non-clustered indices on any foreign key columns – those really help a lot, especially with JOIN’s

    And that’s it!

    Then:

    • observe your system – see when things are slow
    • measure system performance
    • capture a server-side trace to get a representative workload
    • analyse that workload, and see what additional indices might be helpful
    • do tweaks – one at a time
    • measure again and again to see if you’ve improved system performance (or not)

    You need a full, representative workload to see what queries are really common and used a lot – and see what indices might be beneficial for those frequent queries. Otherwise, you might be providing index help for all the wrong queries, and you might actually slow things down …

    You’d be surprised just how rarely non-clustered indices will really help!

    Don’t over-index – it’s just as bad – if not worse – than having no indices at all ! It might be worse, because every index that you have will also need to be maintained over its lifetime… and there ain’t no free lunch – not even here…

    See Kimberly Tripp’s excellent blog post Indexes: just because you can doesn’t mean you should! on the topic – very helpful, lots of insights. Or basically, just read anything Kim has blogged on indexes – she’s the Queen of Indexing and anything she’s posted on her blog is usually extremely helpful and beneficial!

    Furthermore, SQL Server 2005 and newer offer DMV’s (Dynamic Management Views) that allow you to find out what indices are not being used (those can be removed) or which are missing, according to SQL Server’s query optimizer’s opinion. See SQL Server – Find missing and unused indexes for more details. But be aware: those are dynamic views – they’re reset with each system start and might not be totally accurate – don’t just do everything they tell you – take everything with a grain of salt and consider carefully what you do – document it, so that you can undo it, if things get worse rather than better!

    • 0