Данный топик является переводом части первой главы отличной книги для администраторов баз данных вообще и администраторов MySQL в частности, «High Perfomance MySQL, Third Edition»
Представление о том, как компоненты MySQL работают вместе, помогут вам понять этот сервер лучше. Картинка ниже представляет логическую архитектуру MySQL. Ее можно представить в виде трех уровней.
Первый (верхний) уровень содержит сервисы, которые не являются уникальными только для MySQL. Они предоставляют основной сетевой клиент/серверный инструментарий, необходимый серверу: обработка и управление коннектами, аутентификацию, безопасность и т.д.
Второй уровень более интересен. Большинство важнейших компонент MySQL находятся здесь, включая код для разбора запросов, анализа, оптимизации, работу с кешем, и все встроенные функции (даты, времени, математические, и т.д.). Любой функционал, который является общим для всех систем хранения (таких, как MyISAM, InnoDB и т.д.), находится здесь — хранимые процедуры, триггеры, представления, например.
Третий уровень содержит системы хранения данных. Они ответственны за хранение и получение данных, хранящихся «в» MySQL. Подобно разным типам файловых систем в GNU/Linux, каждая система хранения имеет свои преимущества и недостатки. Сервер обменивается информацией с системами хранения через API систем хранения. Этот интерфейс скрывает различия между разными системами хранения, и делает их относительно прозрачными на уровне запросов. Этот API содержит большое количество низкоуровневых функций, которые выполняют операции с базами данных, например «начать транзакцию» или «вернуть строку, содержащую этот первичный ключ». Системы хранения не занимаются разбором SQL и не взаимодействуют друг с другом, они просто отвечают на запросы сервера.
MySQL разбирает запросы для создания внутренней структуры запроса (дерева), затем выполняет несколько различных оптимизаций.
Оптимизации могут включать в себя модифицирование запроса, определение порядка, в котором сервер читает таблицы, выбор индексов и так далее. Вы можете направить оптимизатору в теле запроса ключевые слова, которые могут повлиять на решения оптимизатора. Вы можете также запросить сервер, как он планирует оптимизировать запрос. Эта информация может помочь вам в оптимизации запросов, изменениях схем, чтобы любой запрос выполнялся настолько эффективно, насколько это возможно.
Оптимизатор не заботится о том, какую систему хранения использует таблица, участвующая в запросе, но система хранения влияет на то, как сервер оптимизирует запрос. Оптимизатор опрашивает систему хранения по поводу ее возможностей, стоимости определенных операций, и статистики данных. Например, определенные системы хранения поддерживают такие индексы, которые могут быть эффективными для некоторых запросов.
Кстати, перед тем, как начать разбор запроса, сервер запрашивает кеш запросов, не хранится ли там уже запрос, идентичный данному. И если хранится, то сервер не начинает разбор, а сразу выдает результат. Конечно, кеш работает только для SELECT — запросов.
В следующем топике планируется перевод главы «Concurrency Control» данной книги.
Логическая архитектура MySQL
Представление о том, как компоненты MySQL работают вместе, помогут вам понять этот сервер лучше. Картинка ниже представляет логическую архитектуру MySQL. Ее можно представить в виде трех уровней.
Первый (верхний) уровень содержит сервисы, которые не являются уникальными только для MySQL. Они предоставляют основной сетевой клиент/серверный инструментарий, необходимый серверу: обработка и управление коннектами, аутентификацию, безопасность и т.д.
Второй уровень более интересен. Большинство важнейших компонент MySQL находятся здесь, включая код для разбора запросов, анализа, оптимизации, работу с кешем, и все встроенные функции (даты, времени, математические, и т.д.). Любой функционал, который является общим для всех систем хранения (таких, как MyISAM, InnoDB и т.д.), находится здесь — хранимые процедуры, триггеры, представления, например.
Третий уровень содержит системы хранения данных. Они ответственны за хранение и получение данных, хранящихся «в» MySQL. Подобно разным типам файловых систем в GNU/Linux, каждая система хранения имеет свои преимущества и недостатки. Сервер обменивается информацией с системами хранения через API систем хранения. Этот интерфейс скрывает различия между разными системами хранения, и делает их относительно прозрачными на уровне запросов. Этот API содержит большое количество низкоуровневых функций, которые выполняют операции с базами данных, например «начать транзакцию» или «вернуть строку, содержащую этот первичный ключ». Системы хранения не занимаются разбором SQL и не взаимодействуют друг с другом, они просто отвечают на запросы сервера.
Оптимизация и выполнение
MySQL разбирает запросы для создания внутренней структуры запроса (дерева), затем выполняет несколько различных оптимизаций.
Оптимизации могут включать в себя модифицирование запроса, определение порядка, в котором сервер читает таблицы, выбор индексов и так далее. Вы можете направить оптимизатору в теле запроса ключевые слова, которые могут повлиять на решения оптимизатора. Вы можете также запросить сервер, как он планирует оптимизировать запрос. Эта информация может помочь вам в оптимизации запросов, изменениях схем, чтобы любой запрос выполнялся настолько эффективно, насколько это возможно.
Оптимизатор не заботится о том, какую систему хранения использует таблица, участвующая в запросе, но система хранения влияет на то, как сервер оптимизирует запрос. Оптимизатор опрашивает систему хранения по поводу ее возможностей, стоимости определенных операций, и статистики данных. Например, определенные системы хранения поддерживают такие индексы, которые могут быть эффективными для некоторых запросов.
Кстати, перед тем, как начать разбор запроса, сервер запрашивает кеш запросов, не хранится ли там уже запрос, идентичный данному. И если хранится, то сервер не начинает разбор, а сразу выдает результат. Конечно, кеш работает только для SELECT — запросов.
В следующем топике планируется перевод главы «Concurrency Control» данной книги.