Индексируйте столбец суммы
Быстрее ли создание индекса для суммируемого столбца, чем без индекса?
Ответы 5
Нет. Индексы улучшают поиск, ограничивая количество требуемых проверок. Агрегатная функция (count, max, min, sum, avg) должна независимо проходить все записи в столбце.
Извините, не совсем понятно, о чем вы спрашиваете.
Вы спрашиваете, ускорит ли это запрос, такой как
SELECT product, sum(quantity) FROM receipts
GROUP BY product
если вы добавили индекс количества?
Если это вопрос, то ответ отрицательный. Вообще говоря, индексы полезны, когда вам нужно найти всего несколько строк среди многих; здесь нужны все строки, поэтому индекс не помогает.
Есть неясное исключение (которое применяется так редко, что большинство оптимизаторов БД, вероятно, не утруждают себя реализацией этого трюка). Если ваш запрос окажется
SELECT sum(foo) FROM bar
, где есть индекс для foo, а bar - это таблица с множеством столбцов, можно прочитать полный индекс, что вызовет меньшее попадание, чем если бы вы читали базовую таблицу, и получили ответ непосредственно из индекса - никогда не нужно прикасаться к «настоящему» столу! Однако это довольно редкий случай, и вы захотите проверить, знает ли ваш оптимизатор, что это нужно делать, прежде чем полагаться на это слишком сильно.
+1 Полезный совет: просмотреть план выполнения, созданный оптимизатором.
Всегда ли это так - индексы не могут повлиять на производительность SUM? Что, если мы используем индекс фильтра, указывающий, что значение НЕ ПУСТО? И когда мы используем предложение WHERE для SUM только определенных значений, поможет ли индекс?
Я использую Mysql 5.7 с innodb, и план запроса объясняет, что для суммы столбцов оптимизатор не смотрит за пределы покрывающего индекса.
Оптимизация не такая уж непонятная. Mysql и postgres будут сканировать индекс только в том случае, если вам не нужны значения извне.
Если вы хотите ускорить суммирование, вы можете предварительно материализовать результат. В Oracle используйте Материализованные представления, в MS SQL используйте Индексированные просмотры.
На ваш конкретный вопрос: «Быстрее ли создание индекса для суммируемого столбца, чем без индекса?» - нет.
Ответ на ваш вопрос лежит в ответе Спенсера:
«Агрегатная функция (count, max, min, sum, avg) должна проходить через все записи в суммируемых столбцах, независимо от того».
Просто пояснил контекст столбцов в ответе Спенсера. Тем не менее его ответ правильный.
Если индекс покрывает, он, как правило, будет быстрее. Насколько быстрее будет определяться разницей между количеством столбцов в таблице и числом в индексе. Кроме того, это могло бы быть быстрее при наличии каких-либо критериев фильтрации.
Я обнаружил, что индексация столбца в where (productid здесь) помогает при использовании этого запроса:
ВЫБЕРИТЕ productid, сумму (количество) ИЗ поступлений, ГДЕ productid = 1 GROUP BY productid
Один из моих запросов увеличился с 45 секунд до почти мгновенного после добавления индекса.
Нужен ли вам идентификатор продукта в списке SELECT с одним идентификатором продукта?
да, но, как сказал SquareCog, добавление индекса в productid помогает, потому что вы находите строки на основе productid. В вашем случае вопрос заключается в том, поможет ли добавление индекса количества
Но если все эти столбцы присутствуют в самом индексе, доступ к реальной таблице не требуется, что делает сумму быстрее, чем в случае без индекса.