История MySQL важна не только как классика LAMP-эпохи. Она хорошо показывает, как массовая СУБД эволюционирует через движки хранения, репликацию и платформенные надстройки вроде Vitess.
В инженерной практике глава помогает связать поведение InnoDB, кластеризованных индексов, реплик для чтения и отставания репликации с конкретным профилем нагрузки.
На интервью и архитектурных ревью она помогает честно проговорить границы: где MySQL полностью закрывает транзакционную задачу, а где межрегиональность, тяжёлая аналитика или строгий горизонтальный рост подталкивают к другим вариантам.
Практическая польза главы
Дизайн с учётом движка
Учитывайте особенности InnoDB и кластеризованных индексов при моделировании таблиц, ключей и транзакций.
Стратегия масштабирования чтения
Проектируйте реплики для чтения и переключение на резерв с учётом отставания репликации и требований к консистентности.
Эволюция схемы
Планируйте онлайн-изменения схемы и обратно совместимые миграции, чтобы не ломать высоконагруженную систему.
Позиция на интервью
Показывайте, когда MySQL достаточно, а когда нужны альтернативы для межрегиональных или аналитических нагрузок.
Рамка выбора и редакторский фокус
Фокус главы
эволюции движков хранения MySQL и масштабировании реляционных нагрузок
Профиль нагрузки
Смотрите на критичный пользовательский путь: транзакции, чтения по ключу, индексы, задержку 95-го и 99-го перцентилей и восстановление после отказа.
Когда выбирать
Глава должна отвечать, почему этот движок хорош именно для операционного контура, транзакционной обработки OLTP, кэша или модели с преобладанием записи.
Граница и риск
Нельзя обещать универсальность: каждая СУБД имеет цену в консистентности, миграциях, памяти, индексах или операционной дисциплине.
Связать дальше
Сравнивайте с фреймворком выбора СУБД, репликацией/шардингом и соседними операционными движками.
Источник
MySQL
История MySQL, LAMP-стек, движки хранения, репликация и экосистема масштабирования.
MySQL — это и , которую чаще всего берут как транзакционную основу веб-приложений. И почти всё, что здесь придётся решать, упирается в , и .
Эксплуатационная часть MySQL строится вокруг , , , и понятного пути к .
Для проектирования схемы важны , , и .
MySQL начиналась как быстрый движок для веба и долго славилась скоростью чтения, а не строгими гарантиями. Транзакции, внешние ключи и предсказуемое поведение под нагрузкой пришли позже — вместе с InnoDB. Поэтому выбор здесь почти всегда сводится к движку хранения и к тому, как платформа будет масштабироваться, когда одной машины перестанет хватать.
История и вехи развития
Первый релиз MySQL
23 мая 1995 года выходит первый релиз MySQL; проект быстро набирает популярность в веб-приложениях.
MySQL AB и двойная лицензия
Формируется компания MySQL AB и модель, где GPL сочетается с коммерческой лицензией для корпоративных сценариев.
MySQL 4.0
Платформа дорастает до массовых веб-приложений и закрепляется как буква M в стеке LAMP (Linux, Apache, MySQL, PHP).
MySQL 5.0
Появляются хранимые процедуры, триггеры и представления — логику можно держать ближе к данным, а не только в приложении. Модель языка запросов SQL заметно взрослеет.
Покупка Sun Microsystems
Sun приобретает MySQL AB и получает контроль над одним из ключевых SQL-продуктов с открытым исходным кодом.
Ответвление MariaDB и переход к Oracle
На фоне сделки Sun и Oracle появляется MariaDB; в 2010 году Oracle завершает покупку Sun.
InnoDB становится движком по умолчанию
В ветке MySQL 5.5 InnoDB становится основным движком хранения, усиливая транзакционные гарантии MySQL.
MySQL 5.6
Подтягиваются репликация и эксплуатация: глобальные идентификаторы транзакций (GTID) упрощают переключение и сборку топологии, растёт производительность InnoDB.
MySQL 5.7
Появляются функции для формата JSON, вычисляемые столбцы и доработки оптимизатора — реляционная база начинает аккуратнее держать смешанный профиль нагрузки.
MySQL 8.0
Крупный шаг: общие табличные выражения (CTE), оконные функции и транзакционный словарь данных — аналитические запросы пишутся без обходных приёмов, а метаданные перестают жить отдельно от транзакций.
Новая модель релизов
Появляется LTS-линейка (8.4), а развитие идет через innovation-ветки и последующие мажорные релизы.
MySQL в LAMP-стеке
Популярность MySQL во многом выросла из связки LAMP — классического набора для веб-приложений: Linux + Apache + MySQL + PHP/Perl/Python.
Linux
Операционная система для серверов и веб-хостинга.
Apache
Веб-сервер, обслуживающий запросы приложения.
MySQL
Реляционная база данных для хранения и обработки данных.
PHP / Perl / Python
Языки серверной логики и шаблонов приложения.
Архитектура MySQL по слоям
MySQL делит ответственность между клиентским слоем, SQL-слоем, движками хранения и системным уровнем ОС и файловой системы. Граница между SQL-слоем и движком — ключевая: именно она позволяет менять движок таблицы, не переписывая запросы приложения.
Дополнительные подсистемы работают вокруг основных слоёв и обеспечивают надёжность, репликацию и наблюдаемость.
Журналы
Наблюдаемость
Репликация
DDL и DML: как проходит запрос
DDL меняет схему и метаданные, DML работает с данными и индексами. Различать их важно на практике: тяжёлый DDL на большой таблице способен надолго заблокировать запись, поэтому такие изменения и выносят в онлайн-режим. Ниже — этапы для обоих типов запросов.
Как запрос проходит через MySQL
Сравнение цепочки для DDL (структура) и DML (данные)
Активный шаг
1. Разбор и оптимизация
Оптимизатор строит план выполнения и выбирает индексы.
Работа с данными
- DML затрагивает данные и индексы, но не меняет структуру.
- Основная нагрузка — кеш, журналы и блокировки строк.
- Часто оптимизируется через индексы и выбор плана.
Эволюция движков хранения
Движок хранения в MySQL выбирается на уровне таблицы и определяет, есть ли у неё транзакции, блокировки строк и устойчивость к сбою. Ошибиться здесь дорого: смена движка на живой таблице — это полная перезапись данных под нагрузкой.
InnoDB (по умолчанию)
Транзакционный движок хранения: даёт строгие гарантии, внешние ключи, журналы Redo/Undo для восстановления после сбоя и кластеризованные индексы. Это выбор по умолчанию почти для всех новых таблиц.
MyISAM (устаревающий)
Исторический движок без транзакций и с блокировкой всей таблицы на запись. На рабочих данных он опасен; держать его стоит разве что для понимания того, откуда выросла MySQL.
NDB Cluster
Распределённый движок для MySQL Cluster: узлы не делят общий диск и координируют данные между собой. Платой за отказоустойчивость становится отдельная операционная модель, которая мало похожа на привычную одиночную MySQL.
Документация
Vitess: шардирование для MySQL
Как Vitess делит ключевое пространство на шарды и маршрутизирует запросы к MySQL.
Масштабирование: репликация, MySQL Cluster и Vitess
Репликация
Встроенная репликация разгружает чтение и готовит переключение на резерв. Асинхронный режим быстрее, но допускает отставание реплик; полусинхронный сужает окно потери данных ценой задержки на запись.
MySQL Cluster (NDB)
Кластер на NDB распределяет данные между узлами без общего хранилища и переживает потерю узла. Взамен он требует другой эксплуатации и подходит не любому профилю нагрузки.
Vitess
Слой маршрутизации и шардирования поверх обычных MySQL: ключевое пространство делится на шарды, у каждого свой ведущий узел и реплики. Это путь, когда данные уже не помещаются на один сервер и нужна горизонтальная нарезка.
Вариант архитектуры с Vitess: запросы проходят через слой маршрутизации к нескольким шардам MySQL.
Клиенты
Приложения
Маршрутизация
VTGate
MySQL
Шарды
Ведущий узел и реплики
Связанные главы
- Фреймворк выбора СУБД - Как позиционировать MySQL среди других СУБД с учётом профиля нагрузки, требований к уровню сервиса и операционных ограничений.
- PostgreSQL: история и архитектура - Сравнение двух платформ транзакционной обработки: расширяемость, транзакционная семантика и эксплуатационные компромиссы.
- Репликация и шардинг - Практика масштабирования MySQL через реплики для чтения, переключение на резерв, шардирование и перебалансировку.
- Введение в хранение данных - Как решения по хранению данных связаны с API-контрактами и эволюцией архитектуры продукта.
- Designing Data-Intensive Applications, 2nd Edition (short summary) - Теоретическая база по транзакциям, репликации и консистентности для осознанного выбора SQL-архитектуры.
- Путеводитель по базам данных (краткий обзор) - Практическое руководство по SQL и архитектуре СУБД, которое дополняет обзор MySQL прикладным контекстом.