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