res2001

После того как сгенерировали строку, нужно проверить есть ли такая в базе, если есть - генерировать новую и так пока не получите уникальную строку.
RAND() - она не гарантирует уникальности и не повторяемости.
Как вариант увеличения шансов сгенерировать уникальную строку, можно поиграть параметром RAND - передавать в качестве параметра значение, сгенерированное RAND на предыдущем шагею Последнее значение запоминать и использовать при следующем вызове процедуры. Самое первое значение проще всего получить из текущего timestamp.
Но проверку на уникальность сгенерированной строки все равно нужно делать.

Только подозрение?
Нужно убедится точнее.
Если на линуксе, то посмотрите в top что грузит проц, если винда - менеджер задач.
Естественно есть инструменты для профилирования БД, только нужно знать какой сервер БД вы используете - для каждого свой инструмент.

Гуглите про нормализацию базы данных.
1.Вам нужно вынести name в отдельную таблицу, например назовем ее emploee, в которой будет просто список имен, возможно с какой-либо другой информацией и id, уникальный для каждого имени.
2.Тогда в SAL поля name не будет, а будет id_emploee
3.Меняете имя в таблице employee, автоматически оно поменяется везде, т.к. везде у вас будет фигурировать только id_emploee, а не само имя.

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

Преобразовывайте все 4 поля в строку, конкатенируйте полученные строки, по полученной строке стройте индекс.

Агрегатные функции должны использоваться вместе с фразой group by. В подзапросе они могут использоваться.

Оператор update только выставляет в таблице dvsys_instances поле ArchiveState в значение 2 для отобранных записей. Весь текст запроса - это собственно фильтр для отбора записей.
В последней строке вызывается хранимая процедура dvsys_archive_cards.
Предполагаю, что эта процедура должна производить архивацию записей, у которых ArchiveState=2.

f.id < flights.id - это условие позволяет выбрать все рейсы, которые были до текущего рейса.
Тут надо учесть, что id - это скорее всего уникальное поле с автоинкрементом, поэтому у предыдущих рейсов id будет всегда меньше, чем у текущего.

Убрать оператор with, оставьте от него только внутренний update.
Если вы объявляете with, то его нужно использовать, а он у вас не используется, поэтому и первый update не срабатывает.

Можно. Оператор case вам в помощь.

select p.id as parent_id, c.id, c.name
from paren as p
join child as c on c.parent_id=p.id
order by p.id, c.id

Как написал Decadal из вашего вопроса не ясно как таблицы связываются.
Но вобщем случае нужно использовать join, примерно следующим образом:

select t1.value1, t1.value2, t2.valuea, t3.valuexx, t3.valueyy
from table1 as t1
join table2 as t2 on t2.id1 = t1.id1
join table3 as t3 on t3.id1 = t1.id1
where t1.stamp > XXX
order by t1.stamp

Это схематично. Не зная, как связаны таблицы, трудно что-то больше сказать.

Добавлю свои 5 копеек.
В свое время (90 года, раньше не в курсе), открыв любую книгу по проектированию приложений и баз данных вы бы прочитали именно такой рецепт - вся логика в б.д. на процедурах и триггерах, а клиентская часть - по сути только обеспечивает интерфейс с пользователем. Это клиент-серверная архитектура.
Сейчас же, с переходом на веб, архитектура приложения, работающего с БД стала трехзвенной, поэтому стало возможным вынести логику из БД на уровень веб-серевера/сервера приложений. Это ни плохо и ни хорошо. Просто сейчас так модно - БД просто хранилище данных, а логика вся на сервере приложений. Раньше было модно логику держать в БД.
Хотя и раньше никто не препятствовал делать трехзвенку, но она получалась искусственной и нужны были дополнительные доводы, чтоб ее реализовывать. Сейчас же трехзвенку создавать не надо - она уже есть по факту наличия веб-приложения.
Те кто не разрабатывает веб-приложения просто следуют модному течению.
По уму надо сочетать оба подхода, т.к. какие-то операции лучше реализовывать в БД, а какие-то в сервере приложений или в клиентской части.
Ну и вопрос цены, разумеется - хороший DBA (или программист БД) стоит дороже (и это более редкие звери), чем хороший веб-разрабочик.

1.Сделать необходимые индексы.
2.Разбить большой запрос на несколько маленьких. Даже если по коду будет казаться больше, но обычно несколько маленьких запросов выполняются быстрее, чем один большой. Запросы объединяйте с помощью временных таблиц или union.

PS: Вообще то что вы описали, не есть что-то страшное. Подобные запросы встречаются сплошь и рядом в разнообразных корпоративных системах. Начните с индексов, возможно до второго пункта и не доберетесь.

Заведите в таблице поле по значению которого будете объединять записи, пусть это будет поле tag и пусть в этой таблице будет уникальное поле id.
Запрос с объединением примерно такой:

select T1.*, T2.*
from table T1
join table T2 on T2.tag=T1.tag and T2.id <> T1.id

Все аттрибуты сущности храните не в таблице с сущностью, а в отдельной таблице, в которой дополнительно заводите поля: id сущности, ATTR - код аттрибута, DATEBEG - дата начала действия аттрибута, DATEEND - дата конца действия аттрибута.
При добавлении аттрибута, старый не удаляется, а просто изменяется его DATEEND, и добавляется новая запись аттрибута с DATEEND=null.
Таким образом, вы будете иметь всю историю изменений аттрибутов и можно легко откатиться на любую версию каждого конкретного аттрибута или всех аттрибутов какой-либо сущности.
Т.к. аттрибуты могут быть разных типов, то можно реализовать двумя способами:
1. 1 таблица для аттрибутов одной сущности, в которой содержаться поля для хранения значений аттрибутов всех типов. При этом заполняется только необходимое поле, остальные остаются null;
2.Несколько таблиц для аттрибутов одной сущности, по одной таблице на каждый тип данных аттрибута. Структура таблиц одинакова (возможно за исключением названия поля для значения аттрибута).
В жизни видел обе реализации, вполне приемлемо работают обе. Возможно в первом варианте будет небольшой перерасход дискового пространства за счет не используемых полей и индексов. Реализация в обоих случаях похожая.