Melkij

В slow log куча запросов без индексов

MySQL нагружает процессор

Собственно.

С консоли - запускайте через SELECT SQL_NO_CACHE. Скорей всего у вас query cache активен.

Никак.
Глупый mysql не умеет рекурсивные запросы.

на выбор:
- меняете структуру хранения. nested sets или материализованный путь, например
- вытягиваете всё на приложение и строите там
- делаете МНОГО запросов
- пишете хранимку, которая будет делать много запросов
- если вложенность известна - то через n джойнов можно.

Для начала между работником и учебным заведением связь многие-ко-многим.
Во-вторых, с чего это для новых работников выбираются только новые значения? Можно быть одновременно новым работником и закончить лет *дцать назад именно бывшее тогда учебное заведение. Выбирать можно из всего списка, либо, что лучше, хранить для учебного заведения год открытия и год закрытия (default null) и выбирать подходящие по годам обучения.
Если сохраняете ещё и даты обучения - то важно учесть, что учебное заведение может быть закрыто в любой момент между поступлением и выпуском студента. Поступил в одно заведение, выпустился из другого - запросто.

Если нет особых требований к поиску учебных заведений, то достаточно хранить год закрытия (default null) и ссылку на новую форму после реорганизации, если есть (поэтому тоже default null).
Для вашего примера будет КГПА например с edu_id = 105, reorg_to_id null и КГПУ со своим edu_id, датой закрытия и reorg_to_id = 105

Переключите PDO::ATTR_ERRMODE в единственный адекватный режим PDO::ERRMODE_EXCEPTION.
Нормальный поток исполнения - вас не заботят ошибки в SQL, раз метод вернул управление, значит он был выполнен успешно.
Случилась какая-то ошибка - словили исключение. Если для какой-то конкретной ошибки вам нужна своя реакция - то тогда уже выясняете код именно этой ошибки, смотрите в getCode и реагируете на конкретный код ошибки.

Какие индексы есть? Структура таблицы?
explain (analyze, buffers)?

1. не нужно
2. см. 1
3. если вы упираетесь в CPU, а не в диск. Если в диск - сделает только хуже.
4. сначала выяснить, как ведёт себя имеющаяся табличка. Потом думать. Например, brin по id города. На низкоселективных полях получится внятный компактный индекс.
5. 200гб вполне себе нормальная база. Даже не астрономически дорого целиком в shared_buffers разместить.

Возьмите профилировщик и посмотрите, на чём именно теряете время.

О каком классе СУБД вообще речь?
Например, если речь о транзакционной РСУБД, строки объёмные, то можно сделать так:
create temporary table updatetable(guid uuid not null)
пачками этак по 1000 guid вычитываете guid'ы из источника и записываете в эту временную табличку.
select guid from updatetable where not exists (select 1 from normaltable where normaltable.guid = updatetable.guid)
Так получили список guid, которых в целевой БД нет. Сходили в источник за полной версией всех данных этих guid, пачками записали в целевую БД.

Mysql? Неудобно.

select /**/ from (
    select 123321 as id
    union all
    select 154874
    union all
    select 12233
) as targets
where not exists (
    select 1 from tablename where tablename.id = targets.id
);

Т.е организовать единую точку управления этими серверами.

Может, лучше единую точку управления и делать? ansible/salt/chef/puppet, в конфигурации понаписать инициализацию нужного состояния таблицы.

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

Зачем set? Таблица связей типично состоит из пары внешних ключей на связываемые таблицы. Т.е. обычно два инта и составной первичный ключ.

Возможность есть понаписать триггер. Только сначала хотелось бы понять смысл.

Посмотрите в explain, что планировщик думает по этим запросам. Есть большое подозрение, что хранимка и константный запрос идут по индексу по id, запрос с переменной - как-то иначе.

Одна очевидная грабля:
Значение переменной может изменяться во время выполнения запроса.
Константное значение в запросе и аргумент хранимки - не могут.
Соответственно моё предположение: глупый оптимизатор не смотрит, что в запросе переменная никак не изменяется, значит не может просто взять индекс по id и надо делать что-то другое. Скорей всего seq scan - судя по названию таблицы, данных подпадающих под условие dt <= дата куда больше, чем данных под него не попадающих. Для хорошей работы по индексу надо обратное свойство.

MyISAM

баланс на моем сайте

Сделайте мне это развидеть.

Это безотносительно проблемы. Хранить данные и нетранзакционное хранилище - взаимоисключающие вещи. Используйте единственное транзакционное хранилище в mysql - innodb. И добавьте внешние ключи.

Несколько маловероятно, что это непосредственная проблема, в штатном режиме даже myisam выборочно строки терять не должен так, что это заметил только конкретный пользователь. Более вероятна реакция mysql "аааа, таблица повреждена, я буду говорить только с админом". Впрочем, я давно уже не работал с myisam в продакшене, может и такое поведение тоже характерно.
А вот FK в режиме restrict вполне поможет от странных запросов.

select st.name, count(0) from Sms join Sms_status st on status_id = st.id where st.name in ('sent','not_sent', 'new') group by status_id

Аналогично и первая толпа запросов сворачивается в один простой SQL.

А с учётом сущности данных - имеет смысл их перенести в отдельную таблицу аггрегации и не пересчитывать в рантайме весь массив.