ThunderCat

Чета у вас какая-то странная таблица, user_id_from и user_id_to понятно, а user_id это что и зачем? date должно быть у вас типа datetime, чтобы понимать какое сообщение за каким идет. Соответственно и ORDER BY `date` нужно.

джоин, гроуп бай и конкат()

1) Проверить индексы на таблицах, с такими объемами у вас все должно летать.
2) Кэширование используется на часто вызываемых запросах, где не критично отставание от точных хранимых данных в пределах некоторго заданного временного интервала, например список последних новостей на сайте изменяется не часто, а запрашивается постоянно, есть смысл хранить его в кеше хотя бы 15-30 минут. А у вас ситуация ровно обратная - запрос делается редко, и данные нужны актуальные.
3) к п.1 нужно соответственно добавить проверку, как работают запросы и используются индексы, explain в руки и вперед.

Есть ли способ кэширования таким образом, чтобы не создавалась еще большая нагрузка?

Собственно кэширование есть способ сэкономить на медленных запросах. Как я понимаю в вопросах работы алгоритмов вы не в зуб ногой, больше по настройке формочек в вордпрессе... Кэш создается 1 раз, и используется для всех дальнейших запросов как готовый ответ от бд, на определенный срок. Для этого во многих инструментах кэширования есть штатные методы отслеживания интервала хранения конкретного значения.

Условно: выбираете топ 10 количества просмотров игр, кладете в кэш на час, и пока кэш существует в базу не лезете, тащите из кэша. Как только кэш автоматически очищается - делаете еще раз запрос, опять кладете в кэш... Таким образом вместо 500 запросов в час у вас будет 1 запрос, все остальное будет тащиться из кэша, и данные будут не старше часа по актуальности. Можете сократить / увеличить время кеширования и таким образом балансировать в плане нагрузка/актуальность данных.

insert с WHERE как бы не сосуществуют. Вы можете либо использовать if, либо сделать эту пару ключей уникальной, и использовать insert on duplicate key ignore.

Во первых - всегда форматируйте код, и вам легче, и ошибок меньше, и людям приятно смотреть...

SELECT id name // выполнится, но не так как задумано, не хватает запятых
FROM table1 
LEFT JOIN b as // здесь все совсем плохо
(  
           SELECT worker_id date value //тут уже даже не выполнится
           FROM table2 
           WHERE data = 'интересующая дата'  //date же!
) 
ON table1.id = b.worker_id //могло бы даже работать, но выше куча ошибок
WHERE date = 'null' // так работать не будет. date IS NULL будет, но у вас вроде нужно value проверять?

Кроме прочего - тут должен был быть просто джоин 2 таблиц, без всяких танцев, ну и дата судя по всему должна быть в интервале, а не одно число, хотя тут уже не совсем ясно что там вообще и как хранится. Так же имена полей надо обрамлять `обратными кавычками`

Задача на самом деле нетривиальная, но очень распространенная. Одним из самых "качественных" вариантов решения для стандартной слаборазряжённой базы является выборка максимального и минимального значения первичного автоинкрементного ключа, а затем формирование набора из N случайных чисел между ними средствами языка (пхп, ноды, го, не суть), где N тем больше, чем больше разряженность базы. Далее делается выборка с in, и уже по результатам выборки берется случайная запись из группы полученных. Насколько я помню это самый эффективный и быстрый способ.

Во первых - что у вас называется пином? текст, число, какая длина и в каком формате хранится и для чего используется? Насколько это "секьюрная персональная информация"?

интеджер от 5 до 7 символов

В идеале, если это пин, он должен содержать какое-то определенное количество символов. Это удобно по многим причинам.

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

2 вариант - генерация "налету", например через микротайм, или ранд, не суть. В таком случае конечно же не нужно делать проверку через do while, достаточно сделать селект со сгенерированным значением, если запрос вернул строку - перегенерировать, если вернул пустой результат - можно добавлять. В любом случае поле нужно сделать уникальным, дабы избежать повторений.

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

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

Так же нет необходимости закрывать соединение, оно само автоматически закроется по завершении пхп скрипта.

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