Click here to monitor SSC
SQLServerCentral is supported by Red Gate Software Ltd.
 
Log in  ::  Register  ::  Not logged in
 
 
 
        
Home       Members    Calendar    Who's On


Add to briefcase

Query Performance Using Indexed View Expand / Collapse
Author
Message
Posted Thursday, March 27, 2014 12:41 AM
Grasshopper

GrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopperGrasshopper

Group: General Forum Members
Last Login: Wednesday, April 2, 2014 12:28 AM
Points: 12, Visits: 52
Hello SQL Experts,

Have one table at warehousing side which contains 100 millions of rows. Actually I succeeded to reduce performance(by adding missing indexes) with great extent in case when worst criteria is used but still it is not at acceptable level.

There can be 25 fields used as criteria to query on this table. Some other tables are also using in join but cost of joining those table is low.

Then I come across Indexed view where it is possible to store aggregate result before hand and I can query to this indexed view with NOEXPAND option but designing index view is critical task for me.

1. Do I have to add all fields/columns into view definition which can be part of criteria?? and grouping all those columns to store aggregate results??

2. Also I have to create unique clustered index on this view. which fields I have to to consider part of it?


3.Other non clustered index I do add as required but will this hamper lot of maintenance cost?


If you already have designed indexed views please do provide your views for the same.

hope so I have explained problem here very well.

Many thanks in advance.
Post #1555282
Posted Thursday, March 27, 2014 2:37 AM


Hall of Fame

Hall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of FameHall of Fame

Group: General Forum Members
Last Login: Yesterday @ 7:01 AM
Points: 3,014, Visits: 3,101
Hi,

1. You don't have to add all fields/columns, unless you must to. Indexed view is very close to table. It's biggest utility comes when the goal is to optimize aggregate operations.
2. Follow the same rules for designing indexes as for tables (e.g. http://www.sqlservercentral.com/articles/Indexing/68563/).
3. Consider that indexes updates are affecting views same as tables. However, nonclustered indexes are useful, but try to cover as much as possible with min number of indexes.

Consider the table size, which in your case is pretty big.

Regards,
Igor




Igor Micev,
SQL Server developer at Seavus
www.seavus.com
Post #1555309
Posted Thursday, March 27, 2014 4:33 AM


SSChampion

SSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampionSSChampion

Group: General Forum Members
Last Login: Yesterday @ 6:53 AM
Points: 13,890, Visits: 28,285
I think Igor largely nails it. I'd concentrate the aggregations into the view. That's the stuff that is going to be the most costly in your queries, so doing that work ahead of time is best. As for the rest, it's hard to offer advice without seeing the code and the structures. Read my books? Not great help, but that's about all I can add here.

----------------------------------------------------
"The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood..." Theodore Roosevelt
The Scary DBA
Author of: SQL Server Query Performance Tuning
SQL Server 2012 Query Performance Tuning
SQL Server 2008 Query Performance Tuning Distilled
and
SQL Server Execution Plans

Product Evangelist for Red Gate Software
Post #1555346
« Prev Topic | Next Topic »

Add to briefcase

Permissions Expand / Collapse