Comments 12
Автору следовало бы указать, что многие вещи верны только для определенных баз, иначе как неверных утверждений, типа
Помимо очевидного недостатка, что набор полей кластерного индекса должен быть уникален (т.е. AUTO_INCREMENT использовать не выйдет),
Спасибо, Юра, как всегда интересно и познавательно!
Для "Много чтения, мало записи" можно еще финт ушами — составной индекс по всем полям, участвующим в поиске, где первым идет поле для сортировки. И выбирать двумя запросами: сначала только айдишники, а потом по ним нужные записи целиком. То есть такой вариант битмап индекса, который жрет больше памяти и в целом работает помедленнее, но по крайней мере читаем из памяти по порядку. Но зато его не надо вручную перестраивать :)
Спасибо :). Да, твое решение тоже норм, если искать нужно не по всем полям. Интересное свойство именно кластерного индекса состоит в том, что оно не требует создания отдельной копии данных (для индекса), поэтому в случае, если фильтровать нужно (почти) по всем полям, дополнительный индекс почти ничего не даст.
На счет битмап индекса: его тоже ведь можно обновлять плавно, например сделать из него LSM-структуру, где новые куски (уже отсортированные) битмап-индекса вставляем в виде отдельного индекса в конец и периодически мержим в один большой. Но это вариант только когда данных очень много, да :). Обычно задержка в несколько минут (или как часто перестраивается индекс) для пользователей не так важна.
Используются ли в реальных, больших интернет-магазинах приведённые Вами примеры?
Да, вполне. Про bitmap index, например, есть такая статья: https://habr.com/ru/articles/261137/
Поиск по произвольным параметрам