To properly index your data for performance, you need to understand your data. Hypothetically, let's say I created a census database table:
CREATE TABLE CENSUS ( ID INTEGER NOT NULL, GENDER CHAR(1) NOT NULL, FAVOURITEFOOD NVARCHAR(20) NOT NULL, STATE NVARCHAR(20) NOT NULL );
Due to working with data, I can know that:
- Sex is divided into 50% of men, 50% of women.
- 60% love roast, 20% vegetarian, 20% Asian food, 20% pasta.
- The state is 25% Californian, 25% in New York, and the rest is 1% for each state.
If I wanted to find Masculine people who love fries and live in California, I would think about making a multi-column index, becoming the first STATE (STATE, GENDER, FAVORITY). I make FAVOURITEFOOD the last column in the index. This is because the STATE filter will clip data by 25%, while FAVOURITEFOOD will return most of the database (no better than a full table scan).
If I wanted to find Feminine people who love vegetarian food and live in New York, I would think about creating a multi-column index and starting FAVOURITEFOOD (FAVOURITEFOOD, STATE, GENDER). Here FAVOURITEFOOD beats data by 20%, so it selects the other two columns much better.
If I run BOTH queries often, what index should I do? The answer is:
CREATE INDEX IX_CENSUS_001 ON CENSUS (STATE, GENDER, FAVOURITEFOOD); CREATE INDEX IX_CENSUS_002 ON CENSUS (FAVOURITEFOOD, STATE, GENDER); ANALYZE TABLE CENSUS;
The ANALYZE TABLE command stores the key distribution for a table. Now, when you run any query, it will determine if IX_CENSUS_001 or IX_CENSUS_002 is the best metric for the execution plan.
If I want to start executing various types of queries, I will stop and think about my data again. I may need to add a new index, and I may need to run ANALYZE TABLE again.
So, back to your scenario; it depends on the data that you have in your tables, and on the queries that you want to execute on it.