Дрёму старого пня нарушил раздававшийся в лесу топор дровосека, под корой зашевелились воспоминания и даже, как это ни парадоксально, гипотезы...

sysdba22одна из гипотез была, что при бэкапе/ресторе


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

sysdba22да, был на предприятии массовый update до этого. но такие апдейты там регулярно происходили и раньше, но не приводили
к особым проблемам. по крайней мере таких "зависаний" вообще за 12 лет эксплуатации системы не было ни разу.


Если апдейт был по индексированным полям, реальное содержимое этих индексов ушло от этой "свежей статистики" в неведомые дали, а статистика осталась. И планы некоторых из некоторых запросов стали из оптимальных неприемлемыми.

Давным-давно, когда деревья были молодыми, а пень... мнэээ... дубом, перешёл он с IB4 Classic на IB5 Super. Зачем с 4 на 5 он уже не помнит, а на Super потому что в 5 Classic просто не было. И вскоре попал в обсуждаемую ситуацию. Ядра тогда были у орехов, а у сервера было 4 процессора. Которые дружно упирались в непрогнозируемый момент времени во что-то чрезвычайно с их точки зрения интересное и уходили на 100% в обсуждение между собой этого интересного практически навсегда. Вот так будущий пень и пришёл к Firebird 0.9 с чем-то - в поисках решения проблемы. И поставил, по совету друзей (С), то есть, kdv, опять Classic. Вскоре ситуация с зависом повторилась, но на одном процессоре. Выяснить что это был за запрос и почему он себя так ведёт было уже делом техники. После чего у пня и его отростков начался продолжительный период бурного явного планописательства.

YuRockСтарый плюшевый мишкаИ планы некоторых из некоторых запросов стали из оптимальных неприемлемыми.
Ну, чем хуже план - тем он "ближе к натуралу", скажем так. А при чтении/переборе сервер не только ведь проц грузить должен, а и диск. Понятно, что RAID, SSD, база в памяти и все дела, но прям чтоб на 100% ядро... Где-то какой-то косяк таки есть мне кажется, и надеюсь его поймают, если это так.

Поставь острый натурный эксперимент.

1. На какой-нить табличке с несчастным мульёном записей сделай поле test int.
2. Проапдейть его, в смысле поле, в 0, целиком, всю таблицу.
3. В паре записей проапдейть на 1.
4. Сделай уникальный индекс (test, id).
5. Поселекть с where test=1.
6. Поселекть с where test+0=1.
7. Поселекть с where test=0.
8. Дальше у тебя будет два варианта:
а) Воздать хвалу за оптимизацию оптимизатора, если он в п.7 индекс не подхватит (я не в курсе последних его улучшений).
б) В противном случае - ахренеть.

YuRockМимопроходящийнатуралом иногда спроворнейНу это конечно. Я о случае, когда нужен план с индексом, а срабатывает без него или с неоптимально выбранным. Так или иначе, чтения/запись должны грузить не только проц, а грузится только проц (раз 100%).
Другое дело, что, может, ТС лукавит и на самом деле не 100, а 70-90...

В случае вывернутого наизнанку относительно оптимального на существующих данных порядка перебора таблиц с использованием неподходящих индексов джойна чуть сложнее палки и верёвки 100 и будет.