<SL> That approach is not true is 100% of cases.  It depends on many factors:

-          How many rows are in the table?

-          How what is the selectivity of the columns?

-          Are there common fields/columns (or groups) used in search?

<SL> You need to test/evaluate the best approach for your requirements.

<SL> In our case, we have a table which has 5-120 millions of rows (depending on the client), for which the most common search is by 2 fields (Date & Channel).  There could be between 2000 and 80000 total rows per Date, and there could be between 1 and 40 Channel values (very poor selectivity).  But typically there are only 2000 rows per date+channel, so creating a Date+Channel (actually Channel+Date for the best index compression) yields search performance which is *orders of magnitude* better than using separate indexes.  (SELECT * FROM Table WHERE Channel = xxx and Date = yyyy on *119 million rows* returns 1160 rows in *1.5secs*)

<SL> The engine uses that same index is also used when searches for a range of dates (for a single channel) is used (ie. WHERE Channel = xxx and Date BETWEEN xxx and xxxx).