Vitsliputsli

1) если вам нужен кеш, то используйте его как кеш. т.е. берите из кеша горячие данные, если их там нет, то идите за холодными данными.
2) то, что вы попытались сделать, больше похоже на шардирование, когда данные делят на несколько таблиц, чтобы было меньше данных в одной таблице. Так ли это нужно? У вас сотни миллионов строк в таблице? Но и шардирование делается не так, выбирается критерий деления для пользователей, такой чтобы вы заранее знали в какой таблице лежит пользователь.
А сейчас изза соединений производительность только ухудшается.

Не 10 запросов, а 10 find_in_set. Или 1 регулярка.
Но лучше, нормализуйте базу.

Изменится, но не значительно. И дело не в сетевом лаге, это вообще другой вопрос, а в других расходах на запрос.
Не понял, почему здесь пишут про использование/не использование индекса, в вопросе вы пишите про обращение по id, это надеюсь primary key, а значит в любом случае у нас поиск по этому индексу. Скорее всего как primary key вы используете число (int, bigint и т.п.), а значит у нас индекс BTree (с hash там вообще будет печально с производительностью). Сложность поиска по BTree - это log(n), где n - это порядок дерева. Только вот сложность и производительность не сильно коррелируют. Ведь когда вы будете менять высоту дерева это не просто обратиться к другому адресу в памяти, это нужно как минимум узнать загружена ли эта страница и получить ее адрес. Все это очень усложняет выбор дерева, теоретически не ответишь, нужно смотреть реализацию в MySQL.

Судя по слову current и доке, ваш $results - это итератор. Т.е. скорее всего, даже не нужно получать массив, просто идите foreach по $results, или используйте другие свойства итератора.

Как уже правильно написали, ваш вопрос больше не про связи, а про ограничения (связь у вас присутствует: message.user_id -> user.id). Чаще всего, для контроля целостности базы данных используют ограничения на стороне этой же базы данных. Вы можете сделать этот контроль и в приложении: в этом простом случае, при удалении записи в user нужно будет чтото делать и с зависимыми записями message и все это нужно будет описывать (а ведь связь может быть не прямая, но и через другие записи). Когда база разрастется, появится много новых и сложных связей, вам придется все это контролировать, причем если вы забыли добавить контроль нового элемента вы сразу можете и не заметить, что консистентность нарушена.
При определенных условиях контроль действительно переносят в приложение, но когда понимают чем рискуют, а выигрыш перевешивает. Но это не тот случай, добавить ограничение будет эффективнее.

regexp_substr

Можно и float использовать, если вас не напрягает, когда вы добавляете 1 сатоши, а добавится 2. Прочитайте про числа с плавающей точкой.
Как вариант использовать обычный int, decimal выглядит круто в базе, но в php вам придется использовать int и смысл decimal теряется.

Так как соединение долго не использовалось, MySQL тупо его оборвал.
Используйте для бота systemd unit с перезапуском при ошибке, ошибки бывают разные, пускай перезапускается автоматически. Хоть это и решит проблему, лучше все-таки разрывать соединение, если оно долго не используется. Или, на худой конец восстанавливать его при обрыве.

Они не будут сортироваться, т.е. будут взяты, как прочитаны. Порядок при чтении зависит от движка, если говорить про InnoDB, то в нем данные сортированы по первичному ключу. Этот порядок зависит лишь от внутренних механизмов движка и не гарантируется, расчитывать на него и использовать в ПО нельзя.

Оптимизация это всегда жертва чем-то, ради чего-то. Нельзя просто оптимизировать, нужно выбрать, что улучшать, а затем выбираеть решения, понимая, чем можно пожертвовать. Поэтому начинать оптимизацию нужно тогда, когда знаешь какую проблему решаешь.
Нельзя просто поставить прослойку перед MySQL и все станет хорошо, MySQL итак, очень быстрая СУБД. Но можно поставить, например кеширующий Redis, при условии, что у вас очень много key-value значений и крайне важен быстрый доступ к ним. Это решение не только увеличит занимаемое место и усложнит архитектуру, нужно будет контролировать консистентность баз данных, которая может быть нарушена из-за проблемы инвалидации кеша.
Оптимизация классических СУБД всегда начинается с построения наиболее подходящих индексов. Если этого уже не хватает и скорость чтения недостаточна, то можно ввести репликацию slave и читать из нее. Здесь опять возникнет вопрос дополнительных затрат на место и консистентности, особенно неконсистентности данных из-за лага репликации. Плюс затраты на дополнительное подключение, что впрочем можно решить внедрением proxy.
Далее более сложные варианты, от отказа от foreign keys, до шардирования. Но все это при действительно высоких нагрузках, заниматься этим на данном этапе не стоит, разве что, если есть предпосылки, что к этому придете, то заранее выбрать параметр шардирования (иногда это просто, а бывает очень сложно).

Как настроить базу данных чтобы все данные сначала хранились на Оперативной памяти но при этом сразу записывались на hdd. Естественно если будет перезагрузка все потерятся. И поэтому нужно чтобы на лету записывало на hdd но отдавало при этом с оперативки. Как настроить?

Зачем? Если вам нужно, чтобы СУБД работала быстро, то для этого их и создают, там и так все есть. Зачем придумывать архитектуру СУБД, если это уже сделано? Тем более, не зная ничего о том, как они работают.
Не питайте иллюзий, что вы сейчас придумаете лучшую архитектуру, чем та, над которой работают десятилетия профессионалы. К тому же, примерно как вы описали, так и работает MariaDB.
Не "подкручивайте" настройки, дефолтных настроек вполне достаточно, что-то меняя можно "убить" СУБД. В настройки надо лезть тогда, когда есть конкретная проблема, и понимаешь, не только то, какая настройка может на это повлиять, но и то, какие другие аффекты это вызовет.

Лучше для чего?
В сложных нагруженных решениях используют сборку Mysql от Percona, т.к. выбран нормальный движок для таблиц и отличные инструменты мониторинга. Большинство из них разработаны Percona. Отличные имеется ввиду для Mysql, для других решений бывает и лучше, и это не значит что mysql говно, просто везде свои плюсы и минусы.
Хз почему ChairfaceChippendale пишет, что Percona куда-то канула, на последнем хайлоуде живее всех живых. Да и решения ни куда не исчезают, даже если бы и канула.