Производительность запроса к СУБД SQL в значительной степени зависит от большого числа факторов - насколько фрагментирована таблица (или индекс), свежести и объема данных / статистики индекса, размера ваших кешей данных / того, сколько ЦП / память, сколько строк в таблице, конструкция запроса и т. д. и т. д. и т. д.
Хотя профилирование запросов является необходимой частью настройки производительности, одного этого недостаточно - оно должно быть частью более широкой стратегии оптимизации запросов. Сказать «протестируй и посмотри» не очень полезно (и, на мой взгляд, иногда опасно!) В общем случае из-за недетерминированной природы процесса оптимизации запросов. Один день бега это может быть просто отлично, следующий медленный (или наоборот).
Без понимания основ построения индекса MySQL, какие запросы будут использоваться и как запросы будут использовать индексы, любые специальные тесты в лучшем случае являются удачными догадками, а в худшем - тикают бомбы замедленного действия.
В этом случае существует эмпирическое правило из-за природы построения B-деревьев MySQL. На странице внутренних страниц MySQL: http://forge.mysql.com/wiki/MySQL_Internals_MyISAM#The_.MYI_file вы можете видеть, что в случае неуникального индекса BTREE на двух столбцах MySQL будет хранить объединенные значения в порядке, который вы указываете. В этом конкретном примере они сохранили ASCII (или UNICODE), но в случае целочисленных значений он будет делать что-то похожее (откройте шестнадцатеричный редактор и расшифруйте действительные значения, если вы достаточно отважны!) (Также ссылка здесь http://dev.mysql.com/doc/refman/5.0/en/multiple-column-indexes.html).
Таким образом, эмпирическое правило заключается в том, чтобы сначала поместить самое селективное (ref http://www.akadia.com/services/ora_index_selectivity.html) значение, поскольку это дает обработчику запросов больше информации, чтобы сузить число строк, обработанный. Размещение менее селективного ключа FIRST заставит оптимизатор учитывать больше строк и, если это не то, что вам ТОЧНО нужно, будет неоптимальным по проекту .
Также, чтобы прокомментировать сказанное Эриком: MySQL (или другие СУБД) могут использовать любые / все ключи расширяющимся образом, чтобы помочь сузить поиск - например, если вы помещаете индекс в (A, B, C), тогда запросы, которые имеют WHERE A = .. B =, могут использовать его (в зависимости от), запросы, которые используют WHERE A =, могут использовать его, но запросы, которые запрашивают WHERE C =, не могут (обычно).
Таким образом, это также зависит от характера ваших запросов - если вы всегда запрашиваете WHERE pid = И sid =, то сначала следует выбрать самый селективный (идентификатор продукта), но если вы часто запрашиваете WHERE sid = XXXX сам, тогда sid должен идти первым (ИЛИ просто создайте другой индекс для этой ситуации, если есть различные суммы). Компромисс здесь - время / пространство - наличие дополнительного индекса удовлетворит другой класс запросов за счет дополнительного дискового пространства и увеличения операций ввода-вывода при записи.
Наконец, если вы используете INNODB, вы можете указать «кластеризованный» индекс, который на самом деле сортирует строки на диске (таблицы MyISAM в основном являются кучами). Если вы кластеризуете строки на диске с помощью sid, pid, тогда он фактически сгруппирует их вместе, чтобы вы могли извлекать целые БЛОКИ (или страницы) продуктов за раз, которые будут использовать значительно меньше операций ввода-вывода, чем только BTREE (ref *). 1030 *)
Итак, вы можете понять, почему полезно "проверить и увидеть", но без понимания основ индекса MySQL вы упускаете целый класс оптимизаций.