>As for indexing, if you know that some fields will *always* be used in your searches, I would not define any non-PK/FK
>indexes. With the right server cache and HDD/SDD setup, it would be faster to perform a NATURAL scan of the table then to
>use *any* index for query purposes.

Huh? This makes me curious, Sean. Are you saying that fields containing 255 values have so poor selectivity that NATURAL is better in all cases? I must admit that I have virtually no experience with indexes on fields with that few potential values, but theoretically, if I searched for equality for three such fields, on average 3-4 records (out of 50 million) would match those criteria. Are you saying that NATURAL would be better than combining 3 indexes for such a query?

Set