Как разработчик Java, написание операторов SQL — обычное дело, но знаете ли вы логику обработки операторов SQL? Например, следующий оператор SQL:
select * from user where id=1
После выполнения этого оператора мы получим информацию о пользователе с идентификатором 1. Так что же делает сервер MySQL для этого оператора SQL? В этой статье мы проверим логику обработки операторов SQL в базе данных MySQL.
В чем преимущество знания внутренней логики обработки операторов SQL в базе данных MySQL? Когда мы сталкиваемся с некоторыми аномалиями или проблемами с MySQL, мы можем напрямую определить суть, найти и решить проблему быстрее..
Чтобы лучше понять внутреннюю логику обработки операторов SQL, мы можем сначала взглянуть на схему базовой архитектуры MySQL, чтобы мы могли рассмотреть базу данных MySQL с более высокой точки зрения.Схема базовой архитектуры MySQL выглядит следующим образом:
Из рисунка мы можем четко видеть архитектуру MySQL, каждый модуль и процесс выполнения операторов SQL. База данных MySQL в целом может быть разделена на две части: серверный слой и слой хранения. Слой сервера совместно используются. И слой хранения двигателя может быть продлен в виде плагинов. Заявление SQL, вероятно, пройдет через три модуля: управление ссылками, разбором и оптимизацией и, наконец, на хранение двигателя. Далее давайте поговорим об этих трех модулях.
Управление соединением
Управление соединением — первое препятствие, возникающее при выполнении операторов SQL.Управление соединением похоже на ворота, которые контролируют взаимодействие между клиентом и сервером.Основная работа по управлению соединением — это аутентификация клиента и управление соединением. потоки.
Когда каждый клиент устанавливает соединение с сервером, сервер создает поток для взаимодействия с клиентом. Первая часть взаимодействия заключается в проверке личности клиента. Учетные данные аутентификации основаны на информации хоста, передаваемой, когда клиент инициирует запрос на подключение, имя пользователя, пароль. Если аутентификация не удалась, завершите задачу подключения и вернитеAccess denied for userошибка.
Если аутентификация прошла успешно, управление соединением сделает еще одну вещь, чтобы запросить разрешения пользователя в таблице разрешений.При этом соединении последующие суждения о разрешениях основаны на разрешениях, прочитанных в это время, то есть, соединение После успешного завершения, даже если администратор изменит разрешения этого пользователя, это не повлияет на проверку разрешений этого соединения.
То, что нужно сделать для управления соединением, относительно простое, в основном отвечающее за соединение между клиентом и сервером.Конечно, в потоке соединения управление соединением также было оптимизировано.Не каждый клиент уничтожит поток после выполнения задачи., управление соединениями будет кэшировать эти потоки и ждать новых соединений, которые не будут часто создавать и уничтожать потоки, тем самым экономя накладные расходы.
Анализ и оптимизация
После того, как управление соединением завершено, второй этап выполнения оператора SQL — разбор и оптимизация.Этот шаг очень сложен.Все операции запроса оператора SQL находятся здесь. Мы можем разбить этот шаг на 4 небольших шага.
кэш запросов
На сервере MySQL тоже есть кеш, очень безвкусная функция, зачем? Вы узнаете после прочтения.
После того, как сервер MySQL получит запрос на запрос, он сначала обратится к кешу запросов, чтобы узнать, выполнялся ли этот оператор ранее. Ранее выполненные операторы и их результаты могут кэшироваться непосредственно в памяти в виде пар ключ-значение. Ключ — это оператор запроса, а значение — результат запроса. Если ваш запрос может найти ключ непосредственно в этом кеше, то значение будет возвращено непосредственно клиенту. Если оператора нет в кэше запросов, он перейдет к следующему этапу выполнения. После завершения выполнения результат выполнения будет сохранен в кэше запросов.
Кажется, что нет никаких проблем, это значительно улучшит производительность MySQL, однако, если вы слишком много думаете, частота попаданий в кеш запросов MySQL очень низкая, основная причина в том, что если два запроса запросов различны в любом (например, пробел, комментарии, заглавные буквы) приведет к отсутствию кеша.
Кроме того, кэш может получить неверные данные.В качестве примера некоторых системных функций два вызова одной и той же функции могут давать разные результаты.Например, функция СЕЙЧАС, каждый вызов будет генерировать последнее текущее время.Если эта функция вызывается в запросе запроса, даже если текстовая информация запроса запроса одинакова, два запроса в разное время должны давать разные результаты.Неправильно использовать результат первого запроса напрямую!
В дополнение к этому очень часто происходит аннулирование кеша MySQL.Система кеша MySQL будет контролировать каждую задействованную таблицу, пока структура или данные таблицы изменяются, например, с помощью INSERT, UPDATE, DELETE, TRUNCATE для таблицы TABLE. , ALTER TABLE, DROP TABLE или DROP DATABASE, все кешированные запросы, использующие эту таблицу, будут признаны недействительными и удалены из кеша!
См. здесь Вы знаете, что кеш запросов очень цыпленок, кеширование для базы данных mysql более вредно, поэтому удалили всю функцию кеша запросов непосредственно в MySQL версии 8.0.
Разбор и предварительная обработка
Если кеш запроса не попал, следующим шагом будет вход в формальную фазу запроса. Поскольку запрос, отправленный клиентской программой, представляет собой просто фрагмент текста, серверная программа MySQL должна сначала проанализировать текст.
Во-первых, оператор SQL анализируется по ключевым словам и создается «дерево разбора». Синтаксический анализатор MySQL проверяет и анализирует запрос, используя правила синтаксиса MySQL, например, правильно ли используются ключевые слова, находятся ли ключевые слова в правильном порядке или совпадают ли кавычки до и после.
Предварительная обработка предназначена для дальнейшей проверки того, является ли дерево синтаксического анализа допустимым в соответствии с некоторыми правилами MySQL, такими как существование таблиц данных и столбцов данных, а также синтаксический анализ имен и псевдонимов, чтобы увидеть, не являются ли они неоднозначными.
Оптимизация запросов
После разбора синтаксиса и предварительной обработки вы поймете свои требования, какую таблицу запрашивать, какие столбцы данных запрашивать, каковы условия и т. д. Но какой оптимальный метод запроса использовать? Для этого существует оптимизация запросов Оптимизатор MySQL оптимизирует наши операторы, такие как преобразование внешних соединений во внутренние соединения, упрощение выражений, преобразование подзапросов в соединения и т. д. Результатом оптимизации является создание плана выполнения, в котором указывается, какие индексы следует использовать для запросов и каков порядок соединений между таблицами.
Актуатор
Исполнитель выполнит план выполнения, оптимизированный для запроса, завершит операцию запроса данных, взаимодействуя с механизмом хранения, и вернет окончательный результат данных.
При запуске выполнения вы должны сначала оценить, есть ли у вас разрешение на выполнение запроса к этой таблице T. Если нет, будет возвращена ошибка отсутствия разрешения, как показано ниже (в реализации проекта, если кеш запроса попал , он будет отображаться в кеше запроса. При возврате результатов выполните проверку разрешений. Запрос также вызовет предварительную проверку перед оптимизатором для проверки разрешений).
mysql> select * from user where ID=1;
ERROR 1142 (42000): SELECT command denied to user 'b'@'localhost' for table 'T'
Если у вас есть разрешение, откройте таблицу, чтобы продолжить выполнение. Когда таблица открыта, исполнитель будет использовать интерфейс, предоставляемый движком, в соответствии с определением движка таблицы.
Например, в таблице user в нашем примере, предполагая, что поле ID не имеет индекса, поток выполнения исполнителя выглядит следующим образом:
1. Вызовите интерфейс механизма InnoDB, чтобы взять первую строку таблицы, и определить, равно ли значение идентификатора 10. Если нет, пропустите его, и если да, сохраните эту строку в наборе результатов;
2. Вызовите интерфейс механизма, чтобы получить «следующую строку», и повторяйте ту же логику оценки, пока не будет выбрана последняя строка таблицы.
3. Исполнитель возвращает набор записей, состоящий из всех строк, которые удовлетворяют условиям в описанном выше процессе обхода, клиенту в качестве результирующего набора.
На этом выполнение SQL-запроса завершено, на самом деле это все еще очень сложно внутренне.
механизм хранения
До сих пор оператор SQL выполнялся, но с реальными данными работает механизм хранения, который представляет собой модуль инкапсуляции сервера MySQL для операций хранения и извлечения данных. Мы знаем, что таблица состоит из построчных записей, но это только логическая концепция.Как физически представлять записи, как читать данные из таблицы и как записывать данные в конкретное физическое хранилище, это все хранилище За вещи отвечает движок.
Для достижения различных функций MySQL предоставляет различные механизмы хранения.Конкретные структуры хранения таблиц, управляемые разными механизмами хранения, могут быть разными, и используемые алгоритмы доступа также могут быть разными. Например, механизм хранения InnoDB по умолчанию после MySQL 5.7.
Видно, что выполнение SQL-запроса по-прежнему очень сложное и включает множество модулей. На этом статья заканчивается. Спасибо за прочтение. Надеюсь, эта статья будет полезна вам в учебе и работе. Если вы найдете статью полезной, добро пожаловать лайк + вперед.
наконец
В настоящее время многие большие ребята в Интернете имеют статьи, связанные с внутренней структурой MySQL, Если есть какие-то сходства, пожалуйста, потерпите меня. Нелегко быть оригинальным, и нелегко кодировать слова, я также надеюсь, что вы поддержите это. Если в тексте будут ошибки, надеюсь сообщить о них, спасибо.
Добро пожаловать, чтобы отсканировать код и подписаться на общедоступную учетную запись WeChat: «Технический блог Pingtou Ge», Pingtou Ge будет учиться и добиваться прогресса вместе.