Busy table, to index or not to index

Question

SQL Server, very busy table, holds activity for around 6-10K users at any time and have inserts/updates/deletes on each hit.

I didn't use index on this table as any data written doesn't stay more than 10 minutes.

But while watching activity monitor I've noticed that SQL Server suggests adding an index to that table.

I know keeping index on a table has its costs do you think I should add index?

Update about details: SQL 2008 R2

Table

     [id] [bigint] IDENTITY(1,1) NOT NULL,
     [siteid] [int] NOT NULL,
     [last_seen] [datetime] NOT NULL,
     [ua] [varchar](250) NOT NULL,
     [ip] [varchar](15) NOT NULL,
     [t_id] [int] NOT NULL

Suggested index

ON [dbo].[onlines] ([ua],[ip],[t_id])

Answer 1

Having a good clustering key can actually speed up even your inserts (read Kimberly Tripp's excellent blog post The Clustered Index Debate Continues for a great and thorough explanation, why that is so), And from the looks of it. you have no clustering key at all.

So I would definitely recommend adding a primary/clustering key on your id column - it's perfectly suited for a good clustering key: narrow, static, unique, ever-increasing:

CREATE UNIQUE CLUSTERED INDEX CIX_YourTableName
  ON dbo.YourTableName(ID)

That should speed up everything - inserts, updates, deletes and select, too.

Whether you need additional indices (and which columns to index) depends on your SELECT queries - since you didn't really tell us anything about those, we can only guess into the blue.....

Basically, what you need to do:

• establish a base line - measure your performance
• then apply an index that makes sense - include columns used in WHERE clauses and/or ORDER BY expressions
• measure again and compare

There's really no magic formula to decide whether you need an index, what it is, and how much it'll help your scenario (or how much it'll hurt INSERT performance) - you need to measure yourself, on your database, your hardware, your environment.

Answer 2

Adding an index costs during writes to the table. (INSERT, UPDATE, DELETE operations). It can improve performance on reads (SELECT, UPDATE, DELETE operations). So, if you have more reads than writes then yes, an index can help you. If you read much less than you write then an index can help you as you don't have to read as much (an index is basically a small subset of the table, and if your select only hits that subset then you can speed up reads considerably in some cases)

I would add the index and monitor the performance, if it doesn't work out for you then remove the index. Ultimately, the only way to know for sure is to try it and compare the results.

Answer 3

The time the data exists doesn't tell you much about the need of indexing. But the rate of updates vs reads does. Inserts are fastest without the index. Updates and deletes may be not, because they may benefit from having the index when searching for the record to alter. Selects also benefit from having an index.

So it is usually better to have indices, even when there are many updates to a table. The general exception is a table for logging, to which you usually only write unless that one time when you actually need the log.

But to be sure, you'd best put an index on there and monitor the performance hit or boost.