За почти десять лет, прошедших с момента выхода MySQL 5.7, в мире баз данных многое изменилось. Появились новые подходы к обработке данных, ужесточились требования к безопасности, и даже сам характер приложений стал совершенно иным. MySQL 8.0, увидевший свет в 2018 году, попытался ответить на все эти вызовы, привнеся не только новую функциональность, но и фундаментально иной подход к хранению и обработке данных.
Тем не менее, большое количество команд остаются верны MySQL 5.7, и на то есть веские причины. Для этой статьи мы в команде платформы данных Yandex Cloud постарались непредвзято посмотреть на производительность обеих версий и протестировать её на реальных нагрузках облачной платформы, а не в рамках стерильного тестового стенда. После прочтения вы сможете обоснованно решить, обновляться ли в ближайшем будущем, или точно понять, почему именно в вашем случаем этого делать не стоит.
Почему MySQL 5.7 всё ещё с нами.
«Работает — не трогай» — золотое правило многих IT‑отделов. И мы не можем сказать, что оно всегда неправильное. MySQL 5.7, выпущенный в октябре 2015 года, до сих пор крутится на тысячах серверов, и многие команды не спешат что‑то менять. Почему?
Во‑первых, легаси‑системы. Многие приложения писались под 5.7, когда о JSON в базах данных можно было только мечтать, а оконные функции считались экзотикой. Переписывать эти системы — порой затратно, долго и рискованно.
Во‑вторых, отработанные процессы. Инженеры знают все подводные камни 5.7, умеют его настраивать и поддерживать. У них есть готовые скрипты для мониторинга, бэкапов, они понимают, как реагировать на типовые проблемы.
Но что если эта стабильность — иллюзия? Официальная поддержка MySQL 5.7 завершилась в октябре 2023 года. Теперь никаких патчей безопасности, никаких официальных исправлений. Только поддержка сообщества. Это как ездить на машине, для которой больше не выпускают запчасти.
При этом современные приложения требуют иного подхода к данным. Представьте, что мы пытаемся выполнить сложный аналитический запрос, создавая пирамиду из подзапросов. Или обрабатывать JSON без нормальной индексации. Или вручную решать проблемы, для которых в MySQL 8.0 уже есть готовые решения.
Что в итоге? Понятно, что MySQL 5.7 уже не молод, и стоит обновится, но и ввязываться просто так в апгрейд без хороших обоснований не хочется. Чтобы ответ был взвешен и осознан, а результат не разочаровал, мы собрали небольшую выжимку причин «за» и немного «против» в рамках этого материала.
Чуть дальше мы представим результаты сравнительных тестов производительности на реальных нагрузках внутри Yandex Cloud. Но перед этим расскажем про конкретные преимущества MySQL 8.0, которые могут быть весомым аргументом «за». Уверены, что по итогу вы дополните своё видение, насколько MySQL 8.0 функциональнее, быстрее и стабильнее предыдущих версий, а также насколько он нужен именно вам.
Что принёс MySQL 8.0
Рассмотрим самые интересные новинки восьмой версии: транзакционный словарь данных, улучшенные механизмы безопасности, оконные функции и CTE для аналитики, продвинутую работу с JSON.
Транзакционный словарь данных: от хаоса к порядку
Вы когда‑нибудь сталкивались с ситуацией, когда ALTER TABLE превращался в многочасовое приключение с блокировками и нервными звонками пользователей? В MySQL 5.7 это обычное дело.
Одно из самых фундаментальных изменений в MySQL 8.0 — это переход от разрозненных файлов к единому транзакционному словарю данных. За этой, казалось бы, технической деталью скрывается настоящая революция в надёжности и управляемости базы данных.
Напомним, что в MySQL 5.7 метаданные каждой таблицы хранились в отдельном файле с расширением.frm. Этот подход, унаследованный ещё с древних времен, имел массу проблем: от риска рассинхронизации метаданных при сбоях до сложностей с резервным копированием и восстановлением структуры базы данных. Любой администратор баз данных, столкнувшийся с повреждёнными.frm файлами, знает, насколько «увлекательным» может быть процесс восстановления.
MySQL 8.0 с его транзакционным словарём данных решает проблему блокировок так же элегантно, как светофор решает проблему регулировки движения на перекрёстке. Если в MySQL 5.7 изменение структуры таблицы часто превращалось в «красный свет» для всех операций, то в 8.0 это больше похоже на «зелёный» — большинство DDL‑операций теперь проходит без долгих блокировок других запросов. Добавление новой колонки больше не останавливает вставку данных в существующие столбцы, а создание индекса не превращает базу в замороженную глыбу. Транзакционный словарь данных работает как умный регулировщик, позволяя параллельным операциям проезжать перекрёсток, когда они не мешают друг другу. Это особенно важно в высоконагруженных системах, где каждая миллисекунда простоя на счету.
Также хороший повод задуматься о переезде — появившаяся в MySQL 8.0 динамическая очистка undo и temp tablespace. Больше никакого медленного создания хостов и перезагрузок, как в 5.7. А если у вас база больше 500 ГБ, то добавление новых хостов будет происходить быстрее до двух раз.
Безопасность: прощай, MD5, здравствуй, SHA-2
В мире, где утечки данных становятся практически обыденностью, MySQL 8.0 сделал серьёзный шаг вперед в плане безопасности. В настройках по умолчанию на смену механизму аутентификации mysql_native_password пришёл более современный caching_sha2_password, который ранее был опциональным для версии 5.7. И хотя MySQL 8.0 всё ещё позволяет использовать устаревший mysql_native_password (ви��имо, для обратной совместимости), система настойчиво подталкивает к использованию более защищённого caching_sha2_password. По сути, это как оставить запасной выход через окно при наличии бронированной двери — можно, но зачем?
Новый механизм не только обеспечивает более надёжное хранение паролей, но и лучше защищён от различных видов атак. Старый механизм аутентификации остаётся лишь там, где это действительно необходимо. Первое время это может быть непривычно. Но это обновление механизмов безопасности можно сравнить и с установкой новых замков после переезда в новую квартиру. Да, старые ключи уже не подойдут, какое‑то время придётся привыкать к новым. Но спокойный сон и уверенность в защищённости данных определённо стоят этих усилий.
Теперь перейдём к более приятным улучшениям.
SQL на стероидах: оконные функции и CTE
Задумывались ли вы когда‑нибудь, почему MySQL так долго запрягал, когда речь заходила об аналитических запросах? Старожилы помнят те времена, когда для элементарной аналитики приходилось строить многоэтажные конструкции. Каждый сложный отчёт превращался в детектив, где к концу расследования ты уже забыл, с чего начинал.
Пока PostgreSQL и Oracle играли в четырёхмерные шахматы сложных аналитических операций, MySQL напоминал первоклассника с считавшего на пальцах. И вот — прорыв! Оконные функции и CTE в версии 8.0 — как волшебная палочка для измученных аналитиков. MySQL наконец‑то вышел из технологического подросткового возраста и показал, что тоже умеет быть взрослым. Если раньше для относительно простых аналитических запросов приходилось создавать сложные решения из подзапросов и временных таблиц, то теперь многие задачи решаются красиво и прозрачно.
Возьмём, к примеру, типичную задачу расчёта скользящего среднего по продажам. В MySQL 5.7 для этого пришлось бы городить что‑то вроде самодельного велосипеда, возможно, даже с хранимыми процедурами. В MySQL 8.0 это превращается в элегантный запрос с использованием оконных функций:
-- Создаём тестовую таблицу продаж CREATE TABLE daily_sales ( sale_date DATE, product_id INT, sales_amount DECIMAL(10,2) ); -- Вставляем демонстрационные данные INSERT INTO daily_sales (sale_date, product_id, sales_amount) VALUES ('2023-01-01', 1, 1000.50), ('2023-01-02', 1, 1200.75), ('2023-01-03', 1, 950.25), ('2023-01-04', 1, 1100.50), ('2023-01-05', 1, 1250.00), ('2023-01-06', 1, 1080.75), ('2023-01-07', 1, 1150.25); -- Расчёт скользящего среднего за 3 дня SELECT sale_date, product_id, sales_amount, ROUND(AVG(sales_amount) OVER ( ORDER BY sale_date ROWS BETWEEN 2 PRECEDING AND CURRENT ROW ), 2) as moving_average_3days FROM daily_sales;
А Common Table Expressions (CTE) и вовсе открывают новую главу в написании сложных запросов. Вместо многоэтажных конструкций, где к пятому уровню вложенности уже забываешь, что вообще хотел получить, можно написать читаемый и поддерживаемый код:
WITH customer_totals AS ( SELECT customer_id, region, SUM(order_amount) as total_spent FROM orders GROUP BY customer_id, region ), regional_stats AS ( SELECT region, AVG(total_spent) as avg_spent, MAX(total_spent) as max_spent FROM customer_totals GROUP BY region ) SELECT ct.*, rs.avg_spent as region_average, (ct.total_spent / rs.max_spent * 100) as percent_of_max FROM customer_totals ct JOIN regional_stats rs ON ct.region = rs.region;
Эти новые возможности делают аналитические запросы не только более эффективными, но и гораздо более читаемыми.
Если же ваше приложение активно использует JSON, вас ждёт ещё больше приятных сюрпризов.
JSON: от падчерицы к принцессе
История поддержки JSON в MySQL — как история Золушки, только вместо хрустальной туфельки у нас оптимизация производительности и удобство использования. В версии 5.7 работа с JSON была реализована на уровне «ну хоть что‑то», заставляя разработчиков использовать громоздкие конструкции для извлечения и обработки данных. MySQL 8.0 не просто улучшил существующую функциональность — он переосмыслил сам подход к работе с JSON.
Теперь у нас есть и оптимизированное хранение, и новые функции для работы с JSON‑данными, и даже возможность создавать индексы по значениям внутри JSON‑документов. Это особенно актуально в эпоху микросервисов и гибких схем данных, когда часть данных живёт в классическом реляционном формате, а часть требует более свободного подхода к структуре.
Для примера создадим такую таблицу:
CREATE TABLE users ( id INT PRIMARY KEY AUTO_INCREMENT, profile JSON, settings JSON, created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP ); -- Вставка тестовых данных INSERT INTO users (profile, settings) VALUES ( '{"name": "Иван", "age": 30, "contacts": {"email": "ivan@example.com", "phones": ["+7900123456", "+7900654321"]}}', '{"theme": "dark", "notifications": {"email": true, "push": false}}' ), ( '{"name": "Мария", "age": 25, "contacts": {"email": "maria@example.com", "phones": ["+7900111222"]}}', '{"theme": "light", "notifications": {"email": false, "push": true}}' );
На версии 5.7 работа с ней будет выглядеть следующим образом
-- Извлечение значения из JSON (громоздкая конструкция) SELECT id, JSON_EXTRACT(profile, '$.name') as name, JSON_EXTRACT(profile, '$.contacts.email') as email FROM users; -- Поиск по значению в JSON (без использования индексов) SELECT * FROM users WHERE JSON_EXTRACT(profile, '$.age') > 25; -- Обновление значения в JSON UPDATE users SET profile = JSON_SET( profile, '$.age', JSON_EXTRACT(profile, '$.age') + 1, '$.contacts.email', 'new.email@example.com' ) WHERE id = 1; -- Добавление нового элемента в JSON-массив (сложная конструкция) UPDATE users SET profile = JSON_ARRAY_APPEND( profile, '$.contacts.phones', '+7900999888' ) WHERE id = 1;
А так в 8.0
-- Создание индекса по значению внутри JSON ALTER TABLE users ADD INDEX idx_profile_age ((CAST(profile->>'$.age' AS UNSIGNED))); -- Более удобный синтаксис для извлечения значений SELECT id, profile->>'$.name' as name, profile->>'$.contacts.email' as email FROM users; -- Эффективный поиск с использованием индекса SELECT * FROM users WHERE profile->>'$.age' > 25; -- Обновление нескольких значений одновременно UPDATE users SET settings = JSON_MERGE_PATCH( settings, '{"theme": "dark", "notifications": {"push": true}}' ) WHERE id = 1; -- Новые функции для работы с JSON SELECT id, JSON_PRETTY(profile) as formatted_profile, JSON_SCHEMA_VALID( '{"type": "object", "required": ["name", "age"]}', profile ) as is_valid FROM users; -- Агрегация данных из JSON SELECT JSON_OBJECTAGG(profile->>'$.name', profile->>'$.age') as name_age_map, JSON_ARRAYAGG(profile->>'$.contacts.email') as all_emails FROM users; -- Проверка наличия значения в JSON массиве SELECT * FROM users WHERE JSON_CONTAINS( profile->'$.contacts.phones', '"1234567890"', '$' ); -- Таблица с виртуальными колонками на основе JSON CREATE TABLE products ( id INT PRIMARY KEY AUTO_INCREMENT, data JSON, price DECIMAL(10,2) GENERATED ALWAYS AS (data->>'$.price') STORED, category VARCHAR(50) GENERATED ALWAYS AS (data->>'$.category') VIRTUAL, INDEX idx_price (price), INDEX idx_category (category) );
Если обобщить: на смену громоздким JSON_EXTRACT пришли элегантные операторы -> и ->>, появилась долгожданная возможность создавать индексы по значениям внутри JSON (что превращает медленный перебор в молниеносный поиск), а продвинутые функции для агрегации и валидации данных делают работу с JSON такой же удобной, как с обычными таблицами.
MySQL 8.0 не только оптимизировал хранение JSON в бинарном формате, но и научился выжимать из него максимум производительности, что особенно ценно в современных микросервисных архитектурах. А возможность создавать виртуальные колонки на основе JSON‑полей с последующей индексацией — это как найти философский камень, превращающий гибкость JSON в скорость реляционной модели.
Выглядит отлично, но все эти улучшения вызывают логичный вопрос: как они влияют на главный показатель — производительность? Посмотрим далее.
Производительность: история взлётов и падений
Любые архитектурные изменения всегда сказываются на производительности, причём не всегда предсказуемым образом. MySQL 8.0 не исключение — некоторые операции ускорились, а некоторые, как ни странно, замедлились.
С одной стороны, новый оптимизатор запросов и улучшенная работа с индексами могут дать существенный прирост в определённых сценариях. С другой — некоторые операции, особенно массовые DELETE и UPDATE, в ранних версиях MySQL 8.0 могли работать медленнее, чем в 5.7.
Отдельного упоминания заслуживает история с метадата‑локами. В MySQL 5.7 работа с метаданными (создание таблиц, изменение структуры и так далее) могла превратиться в настоящий кошмар, особенно в системах с активным использованием DDL‑операций. Представьте себе очередь в супермаркете, где на одной кассе пытаются обслужить всех покупателей — примерно так же работали метадата‑локи в MySQL 5.7. В версии 8.0 эта проблема в значительной степени решена, хотя полностью избавиться от взаимных блокировок при работе с метаданными всё ещё невозможно — законы физики никто не отменял.
Приятные мелочи, о которых все забывают
Возьмём невидимые индексы — функциональность, которая кажется избыточной, пока вам не придётся оптимизировать работу продакшн‑БД без возможности остановки. Добавляешь индекс в продакшн‑среде и не знаешь, чего ожидать: либо взлетит, либо всё встанет колом. Чистая русская рулетка! А в восьмёрке появилась действительно полезная фича — можно сделать индекс невидимым для оптимизатора, спокойно потестить, как он влияет на производительность, и только потом включить его в работу.
Это ещё не всё. В MySQL 8.0 добавили EXPLAIN ANALYZE — отличный инструмент для тех, кто занимается оптимизацией запросов. Раньше обычный EXPLAIN показывал только теоретические прикидки оптимизатора о том, как должен выполняться запрос. А теперь добавляете ANALYZE и получаете реальные цифры производительности после выполнения запроса. Никаких предположений — только реальные данные!
Managed Service: как это работает в Yandex Cloud
Прежде чем перейти к тестам, стоит сказать пару слов о среде, в которой мы их проводили. Управляемый MySQL в Yandex Cloud — это не инсталляция в виртуальной машине, а сервис с мониторингом, резервным копированием и автоматическим масштабированием.
На скриншоте ниже показан график Queries per Second (QPS) — это прямая трансляция нашего тестирования MySQL в Yandex Cloud. Такой пример иллюстрирует, что бывает, если проводить замеры не в стерильной лабораторной среде, а в реальном облаке, точно таком же, каким пользуются все пользователи Yandex Cloud.
Давайте разберём сам запрос к системе мониторинга:
alias(series_max("host", "mysql_Questions_rate"{folderId="b1ggn8ha30fa0bhl081b", service="managed-mysql", resource_type="cluster", resource_id="c9q102fj7nqsrj4npthd"}), "{{host}}")
Тут всё интереснее, чем кажется на первый взгляд. Функция series_max показывает максимальное значение метрики mysql_Questions_rate для каждого временного интервала. Параметры в фигурных скобках определяют конкретный кластер MySQL в нашем облаке, а alias помогает получить читаемые имена хостов в легенде.
Хотите увидеть минимальные значения вместо максимальных? Просто замените series_max на series_min. Нужна средняя нагрузка? series_avg к вашим услугам. А можно и вовсе перегруппировать данные по другим параметрам или изменить временное окно — гибкость запросов позволяет получить практически любой срез данных.
Для глубокого анализа все эти данные можно выгрузить в CSV или JSON одним кликом.
Нашей задачей было получить максимально «честные» данные без прикрас, именно поэтому мы использовали те же серверы, ту же инфраструктуру и те же условия, что и в реальной жизни. Результаты таких тестов более показательны: они демонстрируют не теоретическую, а практическую производительность MySQL в облаке.
В целом в наших управляемых базах данных мы подходим к развёртыванию MySQL как к конструктору — можно собрать как простую однохоcтовую конфигурацию для разработки и тестирования, так и распределённый кластер с узлами в разных дата‑центрах для промышленных систем. В отличие от самостоятельного развёртывания, где каждое изменение конфигурации может превратиться в квест с непредсказуемым финалом, в облаке всё сводится к нескольким кликам или API‑вызовам.
Особое внимание стоит уделить системам хранения. Для скоростных маньяков у нас есть локальные SSD, обеспечивающие минимальные задержки при операциях ввода‑вывода. А для тех, кто предпочитает более взвешенный подход, доступны сетевые системы хранения, сочетающие достойную производительность с возможностью гибкого масштабирования ёмкости.
Теперь, когда мы понимаем среду тестирования, давайте разберёмся с методологией и посмотрим, какие именно тесты мы провели для сравнения производительности MySQL 5.7 и 8.0.
Чего нам это стоит и как протестировать
Для тестирования мы использовали sysbench с профилем OLTP (Online Transaction Processing — обработка транзакций в реальном времени). Если говорить простым языком, это как симулировать работу крупного интернет‑магазина в час пик: тысячи покупателей одновременно просматривают товары, добавляют их в корзину, оформляют заказы. Каждое такое действие — это маленькая транзакция, и база данных должна их все обработать быстро и без ошибок.
Такой подход к тестированию позволил нам воссоздать реальные сценарии использования базы данных: множество коротких транзакций, выполняющихся параллельно, точно как в боевых условиях. Мы прогнали серию тестов с разным количеством параллельных потоков: 16, 32, 64 и 128, наблюдая, как базы данных справляются с растущей нагрузкой. Каждый тест длился 5 минут — достаточно долго, чтобы увидеть реальную картину производительности, а не случайные всплески или провалы.
Наше тестовое окружение:
Виртуальные машины s3-c8-m32 с 8 vCPU и 32 ГБ RAM — классический баланс между производительностью и эффективностью.
Диски объёмом 300+ ГБ (все точные параметры закреплены в нашей конфигурации Terraform).
Тестовая база с 10 таблицами, каждая из которых содержит по 500 000 записей.
Однохостовые установки работают на network‑ssd — тут без вариантов, это единственно возможное решение.
Трёххостовые кластеры получили local‑ssd для максимальной производительности.
И заранее поговорим о критической роли правильного выбора системы хранения. В наших тестах мы столкнулись с показательной ситуацией: при использовании network‑ssd небольшого размера графики показали огромный iowait процессора. Всё дело в том, что для network‑ssd производительность напрямую зависит от выделенных параметров диска. Для кластерных инсталляций ситуация оказалась совершенно иной — там мы использовали local‑ssd, что дало совершенно другие показатели производительности.
Вывод прост: выбор системы хранения требует внимательного подхода, иначе можно получить неприятные сюрпризы в виде существенного падения производительности всей системы.
Только чтение: неожиданный поворот
Начнем с самого интересного — операций чтения. Вот что мы увидели:
MySQL 5.7:
16 потоков: 14 883 QPS при latency P95 = 248,83 мс
32 потока: 16 985 QPS при latency P95 = 442,73 мс
64 потока: 18 772 QPS при latency P95 = 787,74 мс
128 потоков: 20 091 QPS при latency P95 = 1453,01 мс
MySQL 8.0:
16 потоков: 13 419 QPS при latency P95 = 277,21 мс
32 потока: 15 438 QPS при latency P95 = 493,24 мс
64 потока: 16 789 QPS при latency P95 = 893,56 мс
128 потоков: 17 624 QPS при latency P95 = 1648,20 мс
MySQL 5.7 показывает большую производительность во всех сценариях чтения. При этом разница становится особенно заметной при увеличении количества потоков.
Смешанная нагрузка: картина меняется
А теперь посмотрим на результаты при смешанной нагрузке (чтение + запись):
MySQL 5.7:
16 потоков: 1 602 QPS при latency P95 = 6 026 мс
32 потока: 2 655 QPS при latency P95 = 7 615 мс
64 потока: 4 723 QPS при latency P95 = 8 484 мс
128 потоков: 8 316 QPS при latency P95 = 9 624 мс
MySQL 8.0:
16 потоков: 1 988 QPS при latency P95 = 5 409 мс
32 потока: 3 692 QPS при latency P95 = 5 709 мс
64 потока: 5 567 QPS при latency P95 = 7 479 мс
128 потоков: 8 843 QPS при latency P95 = 9 977 мс
И вот тут картина становится интереснее! MySQL 8.0 показывает лучшую производительность при смешанной нагрузке, особенно когда дело доходит до параллельных операций.
Что это значит на практике?
Профиль нагрузки имеет значение
Если ваше приложение в основном читает данные — возможно, MySQL 5.7 всё ещё хороший выбор. Но как только в игру вступают операции записи, MySQL 8.0 начинает показывать свои преимущества.Масштабируемость меняется
MySQL 8.0 демонстрирует лучшую масштабируемость при увеличении количества параллельных операций, особенно в сценариях смешанной нагрузкиLatency vs Пропускная способность
Хотя MySQL 8.0 может обрабатывать больше операций в секунду при смешанной нагрузке, это происходит ценой небольшого увеличения latency.
Когда хостов становится три
Если однохостовое тестирование показывает нам базовую производительность MySQL, то тесты на трёх хостах — это уже совсем другая игра. Здесь мы приближаемся к реальным production‑сценариям, где отказоустойчивость и распределённые операции выходят на первый план.
В тестах чтения на трёх хостах мы видим довольно интересную картину. MySQL 5.7 показывает более стабильную производительность при увеличении количества потоков. На 16 потоках обе версии идут практически вровень (около 3 300–3 400 QPS), но при увеличении нагрузки до 256 потоков MySQL 5.7 демонстрирует лучшую масштабируемость, достигая 17 500 QPS против 15 500 QPS у MySQL 8.0.
Что особенно интересно — латентность операций в MySQL 5.7 растёт более предсказуемо. При максимальной нагрузке в 256 потоков 95-й процентиль задержки составляет около 3 982 мс, в то время как MySQL 8.0 показывает более высокие значения — около 4 437 мс.
MySQL 5.7:
16 потоков: 3 312 QPS при latency P95 = 2 009 мс
32 потока: 5 621 QPS при latency P95 = 2 045 мс
64 потока: 9 823 QPS при latency P95 = 2 198 мс
128 потоков: 14 245 QPS при latency P95 = 2 932 мс
256 потоков: 17 540 QPS при latency P95 = 3 982 мс
MySQL 8.0:
16 потоков: 3 338 QPS при latency P95 = 2 009 мс
32 потока: 5 836 QPS при latency P95 = 1 589 мс
64 потока: 10 714 QPS при latency P95 = 1 771 мс
128 потоков: 13 288 QPS при latency P95 = 2 728 мс
256 потоков: 15 498 QPS при latency P95 = 4 437 мс
Тесты с записью
На малых нагрузках (16–64 потока) MySQL 5.7 держится молодцом, демонстрируя даже чуть лучшие показатели производительности. Но стоит только перевалить за отметку в 128 потоков, как MySQL 8.0 начинает показывать свой характер — и какой! Производительность взлетает до небес, хотя и с некоторыми оговорками по части latency.
Что особенно интересно, при максимальной нагрузке в 256 потоков MySQL 8.0 не просто держится наравне с предшественником, а уверенно обгоняет его. И дело тут не только в сухих цифрах QPS. Важно то, как система справляется с возросшей нагрузкой. MySQL 8.0 демонстрирует удивительно стабильное поведение даже под серьёзным давлением, в то время как 5.7 начинает показывать признаки стресса.
В чём же секрет? А секрет, как это часто бывает, кроется в деталях реализации. Помните тот самый транзакционный словарь данных, о котором мы говорили? В распределённой конфигурации он показывает себя во всей красе. Плюс улучшенная обработка блокировок — это именно то, что нужно, когда у вас активно пишутся данные.
Конечно, за всё приходится платить — в случае MySQL 8.0 это выражается в несколько более высокой latency на пиковых нагрузках. Для большинства современных систем это более чем приемлемый компромисс, особенно учитывая общий прирост производительности.
MySQL 5.7:
16 потоков: 1 934 QPS при latency P95 = 5 409 мс
32 потока: 3 609 QPS при latency P95 = 5 507 мс
64 потока: 6 993 QPS при latency P95 = 5 312 мс
128 потоков: 11 261 QPS при latency P95 = 6 835 мс
256 потоков: 15 154 QPS при latency P95 = 12 838 мс
MySQL 8.0:
16 потоков: 1 934 QPS при latency P95 = 5 813 мс
32 потока: 3 420 QPS при latency P95 = 5 507 мс
64 потока: 5 753 QPS при latency P95 = 5 312 мс
128 потоков: 13 557 QPS при latency P95 = 14 047 мс
256 потоков: 15 154 QPS при latency P95 = 14 047 мс
Что дальше?
Технологии не стоят на месте, и хотя MySQL 5.7 всё ещё остаётся вполне работоспособным решением, время неумолимо движется вперёд. Рано или поздно придётся столкнуться с тем, что новые версии библиотек и фреймворков перестанут поддерживать MySQL 5.7, а патчи безопасности станут появляться всё реже. По факту мы уже столкнулись с этим, так как официальная поддержка закончилась 21 октября 2023 года, и сейчас по большей части всё осталось на совести сообщества.
MySQL 8.0 — это не просто новая версия с набором дополнительных функций. Это качественно новый уровень зрелости продукта, который наконец‑то может на равных конкурировать с другими современными СУБД. И хотя процесс перехода может быть непростым, особенно для крупных систем с длинной историей, оно того стоит.
В конце концов, технический долг имеет свойство накапливаться, и чем дольше откладывать переход на актуальную версию, тем сложнее и рискованнее он будет в будущем. Чтобы упростить себе жизнь, можно совместить апгрейд с миграцией в облачную платформу.
Если в качестве облака для миграции вы выберете Yandex Cloud, то с подробными шагами, необходимыми для переезда, можно познакомиться в нашей документации. Если же вы уже клиент нашей облачной платформы, то там же сможете узнать о процессе апгрейда кластера — в рамках этого гайда.