массив, естественно, обрабатывается, но это уже не предмет рассмотрения данной статьи. В данном случае виноват, пропущено многоточие между end loop и return
Есть задачи основные, а есть некая обвязка, которая облегчает сопровождение (но непосредсвтенн но не влияет на решение основных задач, а иногда и мешает, забирая под себя ресурсы). Это как раз такой случай - и переделывать БД под эту задачу никто не будет. поэтому и приходится искать альтернативные варианты решения.
Агрегация и группировка в подзапросе тоже проверялась, но когда нет необходимых индексов (а создание новых специально для этой задачи не предусматривается) - все равно работает медленно. Время - специально еще раз сегодня запустил, после 45 мин работы - снял задачу, дпльше не имеет смысла проверять.
IN/EXISTS тоже проверялся, работает быстрее, но в моем случае при варианте с одним большим запросом все равно медленнее, чем отдельными короткими запросами. Для большого запрса не хватает индексов
Сознательно не приводил здесь планы запросов, статья не про оптимизацию как таковую, а про то, что не нужно бояться иногда отступать от общепринятых принципов построения sql запросов, если это позволяет решить задачу быстрее.
Пересбор статистики реультатов не давал, это проверено. Изменить большой запрос, чтобы он заработал - быстро не получилось. А т.к вариант с несколькими ортаботал за приемлемое для нас время, остановились на нем. Нужно ведь учитывать и то, что невозможно одной задачей заниматься бесконечно, есть и другие...
БД ушёл своппиться - нет, в результате работы запросов в массиве будет около сотни записей
Невозможно оптимально индексировать БД под все задачи, в данном случае индексов для моего запроса нет, и не будет
массив, естественно, обрабатывается, но это уже не предмет рассмотрения данной статьи. В данном случае виноват, пропущено многоточие между end loop и return
Есть задачи основные, а есть некая обвязка, которая облегчает сопровождение (но непосредсвтенн но не влияет на решение основных задач, а иногда и мешает, забирая под себя ресурсы). Это как раз такой случай - и переделывать БД под эту задачу никто не будет. поэтому и приходится искать альтернативные варианты решения.
Агрегация и группировка в подзапросе тоже проверялась, но когда нет необходимых индексов (а создание новых специально для этой задачи не предусматривается) - все равно работает медленно. Время - специально еще раз сегодня запустил, после 45 мин работы - снял задачу, дпльше не имеет смысла проверять.
IN/EXISTS тоже проверялся, работает быстрее, но в моем случае при варианте с одним большим запросом все равно медленнее, чем отдельными короткими запросами. Для большого запрса не хватает индексов
индексов минимальное количество и они заточены под другие задачи
Запрос сджойнами будет выигрышнее, если есть необходимые индексы. В моем случае их нет. И создвавать новые специально для этой задачи возможности нет
Сознательно не приводил здесь планы запросов, статья не про оптимизацию как таковую, а про то, что не нужно бояться иногда отступать от общепринятых принципов построения sql запросов, если это позволяет решить задачу быстрее.
Здесь как раз тот самый случай - с таблицами идет активная работа (каждые сутки добавляются около 10 млн в каждую, примерно столько же удаляются)
Пересбор статистики реультатов не давал, это проверено. Изменить большой запрос, чтобы он заработал - быстро не получилось. А т.к вариант с несколькими ортаботал за приемлемое для нас время, остановились на нем. Нужно ведь учитывать и то, что невозможно одной задачей заниматься бесконечно, есть и другие...