October 26, 2012 at 1:12 pm
1.- After how many records is appropiate to begin to use indexes?
2.- Is it correct to create a nonclustered index on a foreign key before to populate table?, or after? I mean in this way:
a) Create database script with tables and only clustered indexes
b) Create another script to update database with nonclustered indexes "only" for foreign keys (I read is appropiate to do in two steps 'Clustered and Nonclustered')
c) Populate
d) Run another one script with nonclustered index columns to be use to perform selections, like columns used on [order by] clause, or columns deterministics on results (not foreign keys).
Or
a) Create database script with tables and only clustered indexes
b) Populate
c) Create another script to update database with nonclustered indexes (Fk and columns to perform selections)
Or
a) Create database script with tables and only clustered indexes
b) Create another script to update database with all kind of nonclustered indexes
c) Populate
3.- Is it correct to group "foreign key indexes" with normal column indexes?
I mean, if I have two tables (menu_cat and submenu_cat) with a column called [mnu_order] on submenu_cat, I read is it good idea to create index on [mnu_order] field, because is a colum to be used on [order by] clause (all time),, also I have [menu_id](Foreign key), is it correct in this way to do a group index?:
CREATE NONCLUSTERED INDEX [IX_SubMenu] ON [dbo].[subMenu_cat] (
[Menu_iD] ASC,
[mnu_Order] ASC
)
Or I need to separate
CREATE NONCLUSTERED INDEX [IX_SubMenu_Menu_iD] ON [dbo].[subMenu_cat] (
[Menu_iD] ASC
)
CREATE NONCLUSTERED INDEX [IX_SubMenu_mnu_order] ON [dbo].[subMenu_cat] (
[mnu_Order] ASC
)
There is a difference doing this(internally)?, this fields ever will be used on [where] clause.
Thanks in advance, I'm learning about indexes and I have many doubts yet. Sorry for my bad english.
October 26, 2012 at 1:21 pm
1. Set some up right away. You'll forget until performance goes down and then you look bad. I'd create a clustered index right away, and then index PK/FKs as well. The choice of the clustered index depends, so read about choosing them for your application.
2. You have to test. Having non clustered indexes in place can slow a load, or the rebuild can be slower. There's no answer here that's right.
3. Multi-column indexes depend on your queries. Are you using these columns together in joins or filters often? If so, then it makes sense to have them in one index.
October 26, 2012 at 1:42 pm
Thanks for fast repply Steve,
Thank you for your suggestions on points (1 and 2), I will do as you said.
About point 3, yes, mnu_order and menu_id ever will be selected in same query filter, my doubt is, Is it correct to combine fk column and normal column on same group index? Is it the same thing do it together? or I need to do separated like the example?, thank you again 🙂
November 1, 2012 at 10:25 am
It depends. If the FK column is used in the queries, I'd combine them. If it's not, then it won't help you.
You do want an index with the FK column as the first column. This will speed up queries that join the parent and child tables. If it's a query like
select col
from menu m
inner join submenu s
on m.menuid = s.menuid
where mnu_order = @x
then combining these makes sense. However if you are querying the menu_order without the FK at times, then this isn't necessarily going to help. You might need separate indexes that cover separate queries.
Menus typically don't have lots of rows, meanings tens, hundreds of thousands or millions. If these tables are relatively small, < 1000 rows, I'm not sure you're going to get much benefit from spending too much time indexing.
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply