Я хочу добавить, что разные базы данных требуют разных стратегий. Давайте сравним MySQL с InnoDB и PostgreSQL для примера.
InnoDB
Таблицы InnoDB - это в основном индекс b-дерева первичного ключа, который расширен, чтобы включить информацию строки в элемент индекса. Сканирование в физическом порядке не поддерживается, и все сканирования выполняются в логическом порядке. Это означает две вещи:
Последовательное сканирование в Innodb генерирует много случайных дисковых операций ввода-вывода, и
Индекс первичного ключа должен быть пройден независимо от того, использует ли он вторичный индекс.
Поиск в первичном ключе быстрее в этой модели, чем в любом другом подходе.
В этом случае очень важно индексировать достаточно полей в многостраничных таблицах. Типичное правило - индексировать все, что вы хотите отфильтровать.
PostgreSQL
PostgreSQL использует файлы кучи, по одной таблице на файл (в некоторых таблицах может быть много файлов), где кортежи выделяются из свободного пространства этой кучи. Физический порядок сканирования поддерживаются. Чтобы сканирование логического порядка работало, необходимо добавить индекс.
Первичные ключи в PostgreSQL - это в основном подмножество уникальных индексов, где никакие значения не могут быть NULL. УНИКАЛЬНЫЕ ограничения выполняются с использованием неявных индексов, а некоторые другие типы индексов поддерживаются различными операциями, возможными в индексе.
Это означает:
Основные ключевые поиски, предполагающие достаточно большой tablerequire ударяя индексный файл и файл таблицы. Это значительно медленнее, чем в подходе MySQL, когда нужно только пройти по индексу, а строка содержится в индексе.
Сканирование в физическом порядке работает намного лучше, сокращая случайный дисковый ввод-вывод, при котором необходимо обрабатывать значительное количество строк.
Сканирование вторичного индекса работает лучше, чем MySQL, потому что для доступа к физической части таблицы необходимо пройти только один индекс.
В этой модели индексы часто необходимы, но у планировщика есть больше свободы, когда использовать индекс, и последствия его использования часто бывают менее серьезными. Таблицы в целом оптимизированы (а не специализируются на поисках pkey), поэтому требуется меньше индексов.
TL; DR
Знай свою РСУБД.