d'Ivan

В принципе понимание правильное. Почитайте ещё про многоуровневую модель OSI: https://ru.m.wikipedia.org/wiki/Сетевая_модель_OSI
Есть общий протокол работы с протоколами на низком уровне - ASN.1: https://ru.m.wikipedia.org/wiki/ASN.1
Для просмотра http-протокола используйте fiddler (www.telerik.com/fiddler) . Он показывает всю изнанку HTTP(S).
Ну а логику работы по протоколу каждый производитель обеспечивает сам. Протокол только описывает как должен производиться обмен, но как это реализовывать каждой стороне протокол не регламентирует. Поэтому реализация протокола остаётся на совести производителя ПО или оборудования.

Протокол это некоторая договорённость относительно формата передаваемых данных. Набор правил, по которому пакет формируется на передающей стороне и парсится на принимающей. Протокол определяет порядок, размер и назначение полей в пакете данных. Например, в протоколе UDP фиксировано расположение и размер ячеек номера порта, контрольной суммы, размера данных в пакете, допустимые значения размера пакета, и т.д.

Все верно. Только вы говорите о текстовых протоколах.
В общем случае протокол - это договоренность двух систем об интерпретации запросов и передаче результатов выполнения запросов (и их интерпретации на запрашивающей стороне).
SQL - это только половина протокола. Но есть еще ответы от SQL-сервера.
Это тоже часть протокола. Т.о. сам по себе SQL-не определяет способ взаимодействия с SQL-сервером. Но помогает стандартизировать способ генерации запросов для него.

В случае бинарных протоколов все тоже самое, только взаимодействие система организовано таким образом, что человек не в состоянии без спец средств интерпретировать (расшифровать) протокол.
По сути для машины не важно, текстовый протокол, или нет. Для неё это все - двоичные последовательности.
Текстовые протоколы хороши для отладки человеком.
Бинарные для полной утилизации полосы пропускания физического канала.

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

Чтобы к чему то подключиться - нужно чтобы это что то работало.

Если вкратце, то у вас три варианта:
1. оптимизировать запрос
2. вертикальноє масштабирование БД (более мощный сервер)
3. горизонтальное масштабирование БД (шардинг)

То, что вы хотите - ето антипаттерн: https://stackoverflow.com/questions/16721772/mysql...

Прироста не будет.
Но давайте посмотрим на проблему под другим углом:

5кк строк - это ничтожное кол-во. Если у вас происходят селекты по 30 секунд, значит либо у вас не выставлены правильные индексы на те колонки, которые вы селектите, либо вы совершаете LIKE, начинающиеся с %. Индексы не используются при запросах LIKE %...%. Только при LIKE ...%

Ещё одна возможная причина - это хранилище. Посмотрите, не упирается ли всё в этот момент в диски. Если окажется, что в момент тяжёлых запросов у вас высокий iowait, попробуйте мигрировать на площадку с SSD.

На входе невалидный JSON, на выходе JSON::ParserError, вроде всё верно.
Попробуй

str = '[ { "aa": "1" }, { "aa": "2" } ]'

А зачем сборка?
Просто ставьте минимальный Дебиан и на него то что вам нужно, никакого мусора не будет

все просто. Каждый день по 1-2 часа тратите на эту новую технологию. Это тоже ваша работа: изучить и использовать. За это они также обязаны вам платить. Ведь программист - это человек, который находится всегда в обучении.

Не храните фото в базе, храните в папке на диске по uuid, а базе храните уникальный URL. Это нормальная практика.
Не изобретайте велосипед, вы получите оверхед в 5-7 раз как минимум, а как только у будет база в 2-3 гб, тормозить начнет все.
В идеале вам надо получить очень маленькую базу из двух простых таблиц и структуру папок где можно хранить сколько угодно фоток с отдачей через веб сервер

не надо хранить фото в базе