You need to be careful with a composite index (index of more than one
column), they need to be in the right order to be useful. For instance
if you had a composite index that was made up of three columns,
cust-id, order-no and date in that order. If you had a query that
supplied the cust-id, order-no and date, the query would be very
likely to use the index. A query where you only had the cust-id, might
use the index, depending on the spread of cust-id. If however your
query only knew order-no and date it would not use the index as it did
not have a value for the first column (cust-id).

So in answer, it's would probably not be a good idea to put all of the
columns into one index, it would probably hardly ever use it. It is
more likely that you could create composite indexes of 2 or 3 columns
that may work and cut down on the number of indexes you need, but
again you really need to know your application to be sure.

One thing you can do with large composite indexes, is have 'covering'
indexes. If you have all the data columns that a query requires in an
index, the query can get its data from the index only without going to
the table itself. This can be very fast. Say you have a table with 100
columns in it and you have a query that runs a lot of times a day and
is only interested in three columns in the table. If you create an
index of those three columns, the query can get it's data from the
index without reading the table.

Hope this helps

John