digital-garden/Архитектура MySQL.md

50 lines
4.6 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

---
aliases:
tags:
- зрелость/🌱
date:
- - 2024-06-16
zero-link:
- "[[00 MySQL]]"
parents:
linked:
---
В MysSQL есть логический слой, который занимается общими и изолированными от хранения данных операциями: кэширование, построение плана запроса и так далее. А есть конкретный физический слой, который отвечает за хранение данных. Он использует интерфейс подключения, то есть реализации хранилищ могут быть разными. ^42f122
Из-за этого возникают проблемы:
- Репликация. Вынуждены писать несколько журналов, на логическом и физическом уровне
- Индексы. Реализация одного и того же индекса может отличаться в разных хранилищах
- Оптимизатор слабо связан с хранилищем, из-за этого он не может использовать какие-то особенности движка для улучшения производительности.
![](Pasted%20image%2020240613195204.png)
Клиенты, которые обращаются к серверу через функции соответствующего коннектора или C API по протоколу TCP/IP либо UNIX Socket.
Логический слой, общий для всех движков:
- В управлении подключением происходит авторизация. Каждый клиент работает в своем независимом потоке. Каждый поток может кэшироваться сервером.
- Кэш запросов. Представлен одним общим потоком для всех клиентов. Может оказаться узким местом.
- Парсер проверяет синтаксис запроса, запрашивает у хранилищ наличие данных таблиц и полей, права доступа непосредственно к этим полям и проверяет наличие ответа в кэше запросов, после чего передает распарсенный запрос оптимизатору;
- Оптимизатор запрашивает в интерфейсе хранилищ статистику по индексам, на основании которой он строит план запроса, который передает исполнителю;
- Исполнитель. Обращается за данными в хранилище согласно плану запроса. Обновляет значения в кэше запросов.
![](Pasted%20image%2020240528082025.png)
## Оптимизатор
Выбирает самый производительный план.
План запроса, который делает оптимизатор, это не какой-то исполняемый код, а набор инструкций, который передается исполнителю. Это некое предположение о том, как запрос будет выполняться. В отличие от PostrgreSQL, мы не можем посмотреть как фактически был выполнен запрос. Данные от 2015 года, может что-то изменилось. ^432879
Какие пробоемы:
- Из-за архитектуры MySQL
- использует мало статистики по запросам.
- не учитывает особенности хранилищ, нагрузку, буфферы соединений и кэши
Как влиять на оптимизатор?
- Переписать запрос.
- Использовать [индексы](Индексы%20в%20MySQL.md)
- user/force/ignore index. Можем явно указать когда и какие индексы использовать
- straight_join. Можем задать жесткий порядок join таблиц
- @@optimizer_switch. Позволяет включать/отключать правила, которые использует оптимизатор.
- optimizer_prune_level и optimizer_search_depth. Верхняя граница количества вариантов и времени выполнения, которые рассмотрит оптимизатор.