_ _

Че-т у вас какие-то пробелы с реляционной алгеброй.
LEFT JOIN staff-city к staff, получаете N * M записей для худшего случая, где N количество записей в staff, M количество записей в staff-cities и все записи в staff-cities связаны со всеми записями в staff.

Потом программно сворачиваете эти записи в N, вручную собирая staff-cities в массив для каждого staff.

А вы путаете торрент-трекер и морду.
Вот сам трекер. Т.е. сервис, который обслуживает подключения пиров и обрабатывает всю информацию.
Для хранения данных использует MySQL.
xbtt.sourceforge.net/tracker

А вы уже будете лазить в MySQL-базу за необходимой информацией. Дело за малым - сделать генератор .torrent-файла. Формат открытый - уверен, вы справитесь.

Nodejs не стоит, поплывете на асинхронном программировании.

Без триггеров можете сделать проверку записей таблицы на обновление с помощью поля типа updated_at.
Подразумевается, что при обновлении записи в это поле будет сохранено время, когда запись была обновлена.
1. Задаете границу, позже которой будете уведомлять.
2. Дергаете записи, которые позже этой границы, рассылаете уведомления, если такие записи есть.
3. Передвигаете границу на текущее время
4. Через минуту начинаете с пункта 2

Для того, чтобы реализовать dirty checking, можете поля сохранять где-нибудь в Redis, тогда сможете проверять изменившиеся поля для обновленных записей.

Если я правильно понял причину вашего замешательства - $this внутри clone это уже экземпляр-копия.
Т.е. при вызове $objDup = clone $obj;
объект $obj копируется в новый объект $objDup, после чего вызывается ___clone, $this в котором ссылается уже на $objDup.
Т.е. __clone это не обработчик копирования, а хук, который вызывается после копирования в для объекта-копии.
Ну и напоследок: php.net/manual/ru/language.oop5.cloning.php

Может в настройке Apache косяк? Отлуп явно от Apache

Если принять за "PHP" его классическое использование в стеке веб-сервера, то "правильно" - никак.
Правильная реализация - вебсокеты или server-sent events. Все остальное это полный ахтунг по одной простой причине - при более-менее реальных нагрузках нужно минимизировать затраты (CPU и память) на осблуживание одного соединения. В случае PHP это невозможно.
Обычно такие вещи реализуются на асинхронных фреймворках. Именно поэтому сейчас realtime-web так бурно развивается с приходом node.js.
Можете попробовать на phpDaemon что-нибудь наваять.

LEFT JOIN hw_10 ON hw_10.subject_id IN [schedule.`first`, schedule.`second`, schedule.`third`, schedule.`fourth`, ...]

$('.selector-for-multiple-forms').on('submit', function(event){
    var jqForm = $(this), msg = jqForm.serialize();
    event.preventDefault();
    ... 
});

Каждая из форм, отправка которых должна обрабатываться таким образом, должна иметь класс .selector-for-multiple-forms или можете придумать любой удобный вам селектор.

Самый главный вопрос - вы же используете HTTPS?
Без него все ваши хеши можно выловить сниффером трафика.
Что подразумевается под клиентом? Браузер напрямую на ваш сервер? Браузер через сервер стороннего сайта на ваш сервер?
Если браузер, то ваши хеши будут в открытом виде. Можно их угнать и завалить ваш API мусором.

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

Не всякую математику можно обсчитать в "реальном" времени, тем более в условиях ограниченного железа, вы должны это понимать.
Смысла во фразе "Сервер должен быстро работать" чуть менее, чем ноль. У вас каждое вычисление константно в смысле ресурсоемкости? Или сложность линейная? Может, экспоненциальная?
Пока вы это не поймете - смысла говорить о "быстроте" нет никакого.
В любом случае для подобной задачи я бы воспользовался следующей схемой:
1. Клиент отправляет задачу на сервер
2. Сервер регистрирует задачу, отдает клиенту ее номер, саму задачу ставит в очередь
3. Клиент сохраняет данные задачи с полученным от сервера номером с пометкой "выполняется"
4. Воркеры (работающие отдельно от основного процесса веб-сервера) вытаскивают из очереди задания и выполняют непосредственно математические расчеты. Получив результат записывают его в базу, отправляют на устройство, с которого поступила задача, пуш уведомление.

На чем реализовывать - особого значения не имеет, с любым ЯП вам придется потратить примерно одинаковое количество времени.

Проверьте наличие suphp расширения для php. Похоже, он контролирует права, которые выданы php-файлам, чтобы не были слишком открытые.

Логи запросов писать в Elasticsearch

Ну так пишите на PHP, в чем проблема-то?

Вариант в лоб - сделать свою таблицу для хранения текущих счетчиков.
В транзакции UPDATE ids SET id = id + 1, SELECT ids.id
И полученный id используете для вставки.
Или использовать для хранения счетчиков redis.