Есть логический слой под названием MySQL, который занимается общими и изолированными от хранения данных операциями: кэширование, построение плана запроса и так далее. А есть конкретный физический слой, который отвечает за хранение данных. Он использует интерфейс подключения, то есть реализации хранилищ могут быть разными.
Логический слой, общий для всех движков:
-В управлении подключением происходит авторизация. Каждый клиент работает в своем независимом потоке. Каждый поток может кэшироваться сервером.
- Кэш запросов. Представлен одним общим потоком для всех клиентов. Может оказаться узким местом.
- Парсер. Проверяет синтаксис запроса. Проверяет наличие прав доступа. Проверяет наличие ответов в кэше запросов.
- Оптимизатор. Составляет план запроса. Из хранилища запрашивается статистика запросов.
- Исполнитель. Обращается за данными в хранилище согласно плану запроса. Обновляет значения в кэше запросов.
Индексы реализуются на уровне движка хранилища, и каждый движок может предоставлять свою реализацию одного и того же индекса.
До версии 5.5 идентифицировать транзакцию можно было только по имени файла и позиции в этом файле. Потом появились GTID, но надо явно включить gtid_mode =ON. C 5.6.5 GTID используется по умолчанию.
binary log position:
- Пример: mysql-bin.00078:44
- Локальный для сервера
- Обязательно сломается
GTID:
- Пример: 7F33BC78-56CA-44B3-5E33-B34CC7689333:44
- Глобален, генерируется автоматически при коммите
- Бесплатная трассировка
- Простой slave promotion
- ==Используйте его==
## Заметки
- MySQL пишет на диск в три места – хранилище (tablespace), журнал (undo/redo log), и Binary Log
- mariadb -Форк Mysql, который пытается исправить архитектурные ошибки MySQL
