Пабло ответит правильно, но, возможно, вы не поймете, что составной индекс может быть оправдан.
Вы можете иметь несколько индексов, и наличие idx1(tstamp, user_id)
не исключает возможности иметь indx2(tstamp, type)
или idx1reverse(user_id, tstamp)
и т. Д. *
Составные индексы наиболее полезны, когда они охватывают все условия в вашем запросе, поэтому предлагаемый вами индекс будет наиболее полезен для
SELECT * FROM my_table WHERE tstamp = @ts1 AND user_id = @uid AND type = @type
Если вы хотите улучшить производительность таких запросов, вы можете рассмотреть возможность добавления составного индекса.
Недостатком индексов является замедление всех операций обновления. Тем не менее, в большинстве общих приложений выполняется гораздо больше операций выбора, чем обновлений (как с точки зрения транзакций, т. Е. Количества утверждений, так и особенно с точки зрения затронутых / извлеченных записей), и в то же время они гораздо более терпимы к более медленным обновлениям (пользователи в основном оценивают скорость система не к тому времени, когда необходимо обновить запись, а к времени, необходимому для извлечения записей; опять же, YMMV и есть приложения, которые не воспроизводят по таким правилам).
Лучше всего было бы, если бы у вас был какой-то способ проверить производительность базы данных с точки зрения типичных рабочих нагрузок (создать несколько типичных сценариев SQL; независимые и повторяемые или создать модульные тесты на уровне приложения), а затем вы можете объективно настроить свою базу данных. .
EDIT
Также следует понимать, что индексы можно добавлять и удалять, не влияя на систему с точки зрения функциональности. Поэтому вы можете настроить свои индексы позже, во время фактического использования системы - и обычно вы собираете и профилируете медленные SQL-запросы, ища условия, которые могли бы выиграть от добавления индексов.