> Вы совершенно бессовестно в своем ответе порезали начало его ответа, где он
> вел речь о разреженных данных. И именно в этом контексте говорил,
> что возможно лучше от индекса в таком случае вообще отказаться.Фух, это, наверное, магнитные бури какие-то.
Нет в мускле никаких "разреженных данных". Нетути. Есть понятие кардинальности ключа - отношение числа уникальных значений ключа к размеру таблицы К є ]0,1]. Чем выше кардинальность ключа, тем меньше строк соответствует запросу, тем меньше временные таблицы, тем меньше накладные расходы, тем выше скорость выполнения. Скорость выполнения зависит не от "разреженности таблиц", а от объемов промежуточных вычислений. Оптимайзер мускля автоматически и довольно эффективно выстраивает подзапросы в порядке убывания кардинальности, чтобы минимизировать размеры временных таблиц. На "разреженность данных" ему начхать, он про такое ни сном, ни духом.
Если девелупер в таблицу вставляет поле {0,1,NULL}, и строит по нему индекс, да еще потом по этому полю начинает искать, то это не "разреженные данные" - это разжиженные мозги. В таком случае не _отказываться_ следует от индекса, а не строить его изначально. Следует проектировать базу таким образом, чтобы поле с низкой кардинальностью не использовалось соло, а только в качестве финального аккорда в рефайне выборки по более подходящим полям. Потому что в противном случае боттлнек случится даже не по времени выполнения запроса, а по ОЗУ, в котором тупо не поместится временная таблица.
Как-то так, примерно. В любом случае вот это:
"..на больших наборах сильно разряженных данных стоит вобще отказаться от индекса, так как бд сначала бежит по индексу а затем по данным и то и то занимает одинаковое время.."
к нашей вселенной отношения не имеет.
