Как оптимизировать это заявление об обновлении

Question

Допустим, у меня есть таблица с 15 столбцами, которая называется MyTable, и запрос UPDATE выглядит так:

UPDATE MyTable SET relevancy = 1, ruleName = 'myRule' 
WHERE colOne = 'some condition' AND colTwo = 5 ... 
  AND (RELEVANCY <> 1 OR RELEVANCY IS NULL)

... представляет любую комбинацию из 15 столбцов в условии WHERE (т. Е. Это могут быть только col14 и col10 и только col1 или col11 и col14 и т. Д.)

То, что мы пытаемся сделать, это то, что у нас есть таблица с примерно 1M + строками, и у нас есть эти «правила фильтрации», основанные на значениях столбцов, чтобы установить релевантность определенных строк на 1, чтобы пользователи могли сказать что-то вроде: я хочу, чтобы все эти данные из MyTable со значением col1 'hello'. Этот оператор UPDATE также выполняется в цикле (~ 20 раз).

Как оптимизировать этот запрос? Предположим, что оптимизация еще не была проведена, как индексы (у нас этого пока нет, поскольку мы не уверены, какие столбцы индексировать).

Answer 1

Ну, я не вижу ничего явно неправильного в самом запросе, поэтому короткий ответ заключается в том, что вы не можете оптимизировать его, не запустив его сначала и не посмотрев на план запроса. Из-за того, как работает реляционная база данных, очень сложно предсказать, на что будет похожа производительность, просто посмотрев на запрос, поскольку он зависит от многих других скрытых факторов, таких как распределение данных, статистика, предоставленные параметры и другие скрытые внутренние компоненты. .

Тем не менее, я изо всех сил пытаюсь понять преимущество использования этого подхода по сравнению с простым выполнением обычного выбора - преимущество only , которое я вижу, состоит в том, что оно защитит от плохой индексации по пронумерованным столбцам для пользователей, выполняющих SELECT на основе столбца RELEVANCY (который, вероятно, всегда будет правильно проиндексирован).

Кроме того, указанная вами схема, как представляется, ограничивает MyTable возможностью применения только одного правила в любой момент времени, и поэтому вам необходимо выполнить это UPDATE каждый раз, когда фильтр все равно изменяется.

Чего вы пытаетесь достичь?

---

Если вы не можете заранее определить, что пользователь будет запрашивать, единственное, что вы действительно можете сделать с точки зрения индексации, - это индексировать все столбцы (индивидуально) и надеяться на лучшее.

Со многими столбцами вы можете начать видеть снижение производительности во время обновления или вставки в эту таблицу из-за большого количества индексов, которые нуждаются в обновлении, но альтернативой, скорее всего, является сканирование таблицы каждый раз, когда пользователь выполняет поиск в столбце. это не индексируется.

Также полезно, если вы готовы изменять индексы в каждом конкретном случае в случае возникновения проблем с определенными запросами.

Answer 2

Одним из практических правил для ускорения запросов SELECT является индексирование каждого столбца, используемого в выражении JOIN или в предложении WHERE.

Компромисс состоит в том, что запросы UPDATE и DELETE изменяют строку и некоторые или все индексы.Поэтому добавление индексов обычно замедляет обновление.

С 15 столбцами и миллионом строк, я предполагаю, что скорость, которую вы получаете, добавляя индексы, не будет полностью сведена на нет той скоростью, которую вы теряете из-за необходимости обновления базы данных.индексов.Но я могу ошибаться.

Но индексы дешевы.Обновите свою статистику.Измеряйте производительность перед добавлением индексов.Добавьте индексы.Измерить производительность снова.Решите, сохранять ли индексы или отбрасывать их.

Индекс может иметь более одного столбца.Если, например, colOne и colTwo обычно появляются вместе в предложении WHERE, вы можете повысить производительность, создав один индекс для пары столбцов вместо двух индексов, по одному для каждого столбца.Мера, индекс, мера снова.

Большинство баз данных SQL поддерживают некоторые вариации EXPLAIN queryname or SQL statement.Узнайте, что поддерживает ваша база данных, и используйте это для измерения производительности.