Дмитрий Энтелис

Интересная проблема.

В общем случае время выполнения запроса никак не зависит от того локальный он или удаленный.
Могут быть микро потери времени на передачу самого запроса (если он реально длинный) и заметные потери времени на передачу ответа (опять же если он огромный).

По пунктам того что Вы пишите:

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

Запросы реально исполняются несколько минут? Какой объем данных передается в ответе? Какой канал между серверами, не забивается ли он? Потребление памяти/процессора на SQL сервере в момент выполнения запроса?

Есть тупая идея увеличить max_connections, но я сомневаюсь что в Вашем случае это поможет, скорее всего проблема не в этом.

Это при том, что подключение к удаленной БД происходит прямо перед запросом, а закрытие подключения сразу после.

Можно так же попробовать использовать persistent connection, не будет оверхеда на постоянные подключения/отключения.

Возможно надо посмотреть в сторону оптимизации самих запросов, дробления их на части итд.

Не очень понял при чем тут Apache, если мы про синхронизацию sql говорим, но Вы бы начали с того зачем Вам это нужно. Потому что в общем случае, без адского геморроя, ответ нет.

Если нужно синхронизировать только структуру - любой менеджер миграций структуры, мне лично нравится https://phinx.org/ но есть много альтернатив.
Если нужно разово переносить "наработки за день"- можно сделать простенький скриптик с mysqldump и переносить им.

Любые решения с multi-master репликацией работают достаточно омерзительно, накладывают серьезные ограничения на запросы и требуют стабильного соединения между серверами.

Я стесняюсь спросить - а зачем вообще это? Не проще на бекенде делать нумерацию строк если уж так надо?
Или в чем вообще задача?

Если это логи, то:
a) зачем там индекс?
б) подумать нужно ли хранить сырые данные вообще, или можно сразу агрегировать что то?
Плюсую Леонид Сысолетин , решение с суточной таблицей живое.

Ну совсем основы это.
Без order by порядок произвольный.
При order by по не уникальном полю - порядок подсортировки произвольный, используйте несколько сортировок одновременно.
Изменение порядка связано с текущим состояние сервера, кешей итд - даже при "одновременно" выполненных запросах - порядок кортежей в выдаче может отличаться если нет сортировки!

Поиск ближайших объектов на карте?

Сформулировать требования, обратиться на фриланс, получить решение.

Организация хранения статуса новых постов?

Если считать совсем честно (по постам) - то вопрос отлично бьется с Как организовать удаления записей из ленты пользователя?
Если устраивает вариант не совсем честного подсчета - то решение хранить для каждого пользователя lastActivity в каждом блоге на который он подписан - мне кажется вполне оптимальной

Мне кажется наиболее рациональное решение - выбрать все данные из Вашей таблицы за нужный период, и за 1 проход цикла в любом ЯП составить требуемую табличку.

Это одна из задач которые не имеют однозначно правильного решения.
В любом случае решение будет затратным по ресурсам.

Я знаю 2 варианты:

1) Табличка hidden_post вида user_id, post_id
Пишем туда посты которые скрываем, на выводе фильтруем.
[+] требуется не много дополнительного места для хранения
[-] геморройная сборка ленты новостей (на больших данных where post_id not in (...) использовать нельзя )

2) хранить для каждого пользователя список id постов которые он должен видеть
[+] простой вывод ленты постов пользователя
[+] можно реализовывать всякие хитрые правила какой пользователь видит какой пост.
[-] требуется МНОГО места
[-] сложный код обновления этих списков
[-] лента пользователя не бесконечная скорее всего.

В принципе варианты можно совместить, для свежих постов вариант 2, для старых - вариант 1.

Учтите что решение IceJOKER и Михаил Тодерашко будет работать ОЧЕНЬ медленно на даже на сравнительно небольшой базе.
Такая сортировка не использует индексы.
При каждом запросе, для каждой строки будет вычисляться значение функции TRIM, а потом еще и сортироваться.

Правильное на мой взгляд решение - обновить поле name так что бы в нем не было кавычек.
Если это не возможно - создать новое поле без кавычек и сортировать по нему.