select o.name table_name, i.name index_name, user_seeks, user_scans, user_lookups, user_updates, used_page_count * 8 used_kb
from sys.dm_db_index_usage_stats s
join sys.objects o on o.object_id = s.object_id
join sys.indexes i on i.object_id = s.object_id and i.index_id = s.index_id
join sys.dm_db_partition_stats ps on ps.object_id = i.object_id and ps.index_id = i.index_id
where s.database_id = db_id() — only current database
and s.index_id > 1 — omit heaps
and (user_seeks = 0 and user_scans = 0)
order by used_kb desc

Your script sounds very interesting. I did write an application that did a similar things using SQL SMO, reporting on the tables and indexes in a database and how much space they used. In fact, it could do this for all databases on all Servers on a network . However, I did not even think about the issue of checking if an index is used or not. I would love to know how you checked in an index is used or not.

I wrote a script that goes through every index in the db, checks if they aren’t used and returns how many kilobytes they take disk space. I ran it through one of our badly behaving database and got some interesting results. Unused indexes, that were probably inserted “just to be sure”, takes space A LOT and are updated a lot. So they are there just ruining performance.

At the same time there are some queries that needs indexing badly. Although tables has indexes they aren’t used because all the joins and indexes doesn’t match.

I also found different versions of SQL Server behave differently. When loading millions of rows into SQL Server 2000 it proved best to drop the indexes, do the insert and rebuild them. With the same system on SQL Server 2005 it is no longer neccessary to do that.

Nice cartoon..

Always I can see, you suggest people to tune up Indexes for query performance, and that is good practice indeed.
But I believe joins used in query also affects in different ways. Tuning up Joins in proper way can improve the performance.

Sometimes we use Join with select query with join statement and sometimes we use table name with join statement.

Can you please write about using smart ways of using joins to improve performance.
When not to use sub queries and when not to use joins.

You wrote about basics of joins here
http://blog.sqlauthority.com/2009/04/13/sql-server-introduction-to-joins-basic-of-joins/

It will be my pleasure if you write or refer some article for best ideas of using joins and sub queries, when to use and not to use.

Can you write about how to identify and understand “Execution Plans”

Thanks a lot for all your Posts..

Hi all readers, please give your suggestions and ideas about my question.

Thanks.

Indexing is a critical issue and Planning of them should be done carefully. Which fields to be made as clustered indexed and their data type(ideally should be of fix width and non nullable). Which fields to be used in non clustered index? Also Covering Indexes and Filtered Indexes. Creating Indexes is important but too many indexes can also cause performance issues. Monitoring, Indexes that are not in use and fragmentation of Indexes. Using Re-Organize and Re-Build(should be used when fragmentation is quite high as it can cause huge transaction logs, in full recovery mode). In all it is a very important aspect of performance tuning.

But I’m seeing more and more totally non-indexed databases these days. Even databases which has tables without clustered index. There’s one database which was crawling because a single select could do thousands table scans. In these cases it is totally safe to blurt “create index on it”.

That picture tells me that,the GREEN MAN knows the structure of the database and the BLACK MAN’s knowledge on the subject……

Can you elaborate each point with example ?
Anyone ?

Thanks.