Принцип управления параллелизмом Mysql

MySQL

Mysql — это широко распространенная реляционная база данных с открытым исходным кодом, предоставляющая высокопроизводительные службы хранения данных. Когда мы занимаемся серверной разработкой, узким местом в производительности часто является не само приложение, а уровень базы данных. Таким образом, овладение некоторыми базовыми принципами Mysql поможет нам лучше понять Mysql, выполнить настройку производительности Mysql и разработать высокопроизводительные серверные службы.

Логическая архитектура Mysql

Логическая архитектура Mysql выглядит следующим образом:

Mysql架构图

Верхний уровень обрабатывает соединения от клиентов. В основном выполняют обработку соединений, аутентификацию авторизации, безопасность и т. д. Mysql поддерживает пул потоков на этом уровне для обработки соединений от клиентов. Mysql может использовать аутентификацию по имени пользователя и паролю или может использовать аутентификацию на основе сертификата X.509 на основе SSL.

Второй уровень состоит из трех частей: кэша запросов, синтаксического анализатора и оптимизатора. Синтаксический анализатор используется для синтаксического анализа оператора SQL, а оптимизатор оптимизирует проанализированный оператор. Перед парсингом запроса сервер сначала проверит кеш запросов, и если в нем будет найден соответствующий результат запроса, он сразу вернет результат запроса, не выполняя парсинг запроса и оптимизацию. На этом уровне реализованы хранимые процедуры, триггеры, представления и т. д.

Третий уровень — это механизм хранения, механизм хранения в MySQL, отвечающий за хранение данных, извлечение данных, открытие транзакции и так далее. Механизм хранения взаимодействует с верхним уровнем через API, который скрывает различия между различными механизмами хранения, так что эти различия в уровне процесса запроса прозрачны. Storage Engine не будет анализировать SQL.

Наиболее часто используемым механизмом хранения для Mysql является InnoDB.

Параллельный контроль MySQL

Если несколько потоков работают с данными одновременно, это может вызвать проблемы с контролем параллелизма. В следующей части этой статьи будет рассказано, как Mysql управляет одновременным чтением и записью.

Блокировка чтения-записи

Если несколько потоков только читают данные, они могут фактически читать вместе, не влияя друг на друга.В это время следует использовать «блокировку чтения», также известную как общая блокировка. Потоки, которые получают блокировки чтения, не блокируют друг друга и могут читать ресурс одновременно.

Если потоку необходимо записать данные, он должен использовать «блокировку записи», также известную как монопольная блокировка. Блокировки записи блокируют другие блокировки записи и чтения до завершения операции записи.

Детализация блокировки

Сначала определите концепцию: чем меньше данных на данном ресурсе необходимо заблокировать, тем больший объем параллелизма может поддерживать система. Но блокировка также потребляет ресурсы.Если система тратит много времени на управление блокировками вместо доступа к данным, это может повлиять на производительность системы.

Таким образом, хорошая "стратегия блокировки" состоит в поиске баланса между накладными расходами на блокировку и безопасностью данных.Mysql поддерживает архитектуру нескольких механизмов хранения, и каждый механизм хранения может реализовать свою собственную стратегию блокировки и степень детализации блокировки.

Блокировки таблицы и блокировки строк

Блокировка таблицы, как следует из ее названия, блокирует всю таблицу. Накладные расходы на блокировку таблицы относительно невелики. После добавления блокировки записи в таблицу все операции чтения и записи в таблице другими пользователями будут заблокированы. В Mysql, хотя механизм хранения может обеспечивать свои собственные блокировки, Mysql иногда использует блокировки таблицы, такие какALTER TABLEзаявления, такие как.

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

Блокировки на уровне строк блокируют всю строку, что может в наибольшей степени поддерживать параллельную обработку, но накладные расходы на добавление и разблокировку также будут относительно большими. Блокировки на уровне строк реализуются только на уровне механизма хранения, и все механизмы хранения реализуют блокировки на уровне строк по-своему.

MVCC

MVCC — это «управление параллелизмом нескольких версий», который можно рассматривать как вариант блокировок на уровне строк, но во многих случаях он позволяет избежать операций блокировки, поэтому накладные расходы ниже.

Все основные реляционные базы данных реализуют MVCC, но механизмы реализации различаются. На самом деле у MVCC нет единого стандарта. Но большинство из них реализуют неблокирующие операции чтения, а операции записи блокируют только нужные строки.

MVCC гарантирует, что данные, видимые в каждой транзакции во время выполнения, непротиворечивы. Однако разные транзакции могут одновременно видеть разные данные для одной и той же таблицы из-за разного времени запуска.

В движке Mysql InnoDB это достигается за счет сохранения двух скрытых столбцов за каждой строкой записей. Один содержит время создания строки, а другой — время истечения срока действия (или удаления) строки.

На самом деле хранится не фактическая временная метка, а «номер версии системы».

При каждом запуске транзакции номер версии системы увеличивается. В начале транзакции номер версии системы используется как номер версии транзакции для сравнения с номером версии запрошенной строки. Ниже описано, как номера версий работают в обычных операциях CRUD:

INSERT

Сохраните номер текущей версии системы в качестве номера версии линии.

DELETE

Сохраните номер текущей версии системы в «удалить версию» этой строки данных.

UPDATE

Вставьте новую строку, сохраните номер текущей версии системы в качестве номера версии строки и сохраните номер текущей версии системы в «удалить версию» исходной строки.

SELECT

  • Находит только строки с более ранней версией, чем текущая версия транзакции. Это гарантирует, что все строки, прочитанные транзакцией, либо существовали ранее, либо были вставлены или изменены самой транзакцией.
  • «Версия удаления» строки либо не определена, либо больше, чем текущий номер версии транзакции. Это гарантирует, что строки, прочитанные транзакцией, не были удалены перед транзакцией.

MVCC работает только при двух уровнях изоляции, REPEATABLE READ и READ COMMITTED, а два других уровня изоляции не могут работать. Поскольку READ UNCOMMITTED всегда считывает последнюю строку данных, а не строку данных, соответствующую текущей версии транзакции. SERIALIZABLE блокирует чтение всех строк.