digital-garden/wiki/zero/00 MySQL.md

3.5 KiB
Raw Blame History

aliases tags zero-link
MySQL
type/zero-link
00 Базы Данных

Архитектура MySQL

Есть логический слой под названием 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