Simple Question SQL Index

Belias
Member Posts: 2,998
Nav 2009sp1, sql2005
hi everyone, i think this is a very simple question, i think: i want to create a new key on 2 fields, that are both option type --> not selective.
There are no sumindexes on this index and i wanted to set the key like this:
Key: OptionField1,Optionfield2
SQLIndex: Primarykeyfield,OptionField1,OptionField2 (the default index would be OptionField1,OptionField2,Primarykeyfield)
Is this modification effective?or is it pointless?is it risky? (i know about some issues about sqlindex property)
hi everyone, i think this is a very simple question, i think: i want to create a new key on 2 fields, that are both option type --> not selective.
There are no sumindexes on this index and i wanted to set the key like this:
Key: OptionField1,Optionfield2
SQLIndex: Primarykeyfield,OptionField1,OptionField2 (the default index would be OptionField1,OptionField2,Primarykeyfield)
Is this modification effective?or is it pointless?is it risky? (i know about some issues about sqlindex property)
0
Answers
-
A new index is only useful if your filters retain few records (5% or less of the total records in the table), otherwise SQL will NOT use the index and keep using the clustered index.
An example:
T21:"Customer Ledger Entry" with 1.000.000 records
A filter on "Open" in is not useful if you want all the closed records (probably 990.000 records).
But if you want all "Open" records (about 10.000), the filter can be useful (but it is not guaranteed).
So if you think it might be useful, create it and see if SQL really uses it.Regards,Alain Krikilion
No PM,please use the forum. || May the <SOLVED>-attribute be in your title!0 -
Well really it depends on the version. In the newer versions, SQL really has no choice of what index to use, it works the same as Native, you tell SQL what to use.
So if you plan to filter on these fields and its a big table then you need the indexes irrespective of how selective they may be.David Singleton0 -
David Singleton wrote:Well really it depends on the version. In the newer versions, SQL really has no choice of what index to use, it works the same as Native, you tell SQL what to use.
So if you plan to filter on these fields and its a big table then you need the indexes irrespective of how selective they may be.
i also thought that nav (SQL) would have follow my instruction, but it didn't...0 -
-
As long as the ORDER BY clause matches the index exactly it should be forced to use the index. If the ORDER BY clause doesn't match exactly, it often reverts to a clustered index scan.0
-
I think the person that made these Dynamic Cursors changes in Navision was reading the Harry Potter books whilst coming up with this solution.David Singleton0
-
I couldn't post this yesterday, (no connection) sorry...
My sql plan said Clustered index seek, not scan...i have to retry the test, maybe there was some filter on the primari key, too... :-k0
Categories
- All Categories
- 73 General
- 73 Announcements
- 66.6K Microsoft Dynamics NAV
- 18.7K NAV Three Tier
- 38.4K NAV/Navision Classic Client
- 3.6K Navision Attain
- 2.4K Navision Financials
- 116 Navision DOS
- 851 Navision e-Commerce
- 1K NAV Tips & Tricks
- 772 NAV Dutch speaking only
- 617 NAV Courses, Exams & Certification
- 2K Microsoft Dynamics-Other
- 1.5K Dynamics AX
- 320 Dynamics CRM
- 111 Dynamics GP
- 10 Dynamics SL
- 1.5K Other
- 990 SQL General
- 383 SQL Performance
- 34 SQL Tips & Tricks
- 35 Design Patterns (General & Best Practices)
- 1 Architectural Patterns
- 10 Design Patterns
- 5 Implementation Patterns
- 53 3rd Party Products, Services & Events
- 1.6K General
- 1.1K General Chat
- 1.6K Website
- 83 Testing
- 1.2K Download section
- 23 How Tos section
- 252 Feedback
- 12 NAV TechDays 2013 Sessions
- 13 NAV TechDays 2012 Sessions