🗊Презентация Оптимизация запросов в реляционных БД

Оптимизация запросов в реляционных БД Николай Александрович Шестаков Томский Политехнический Университет/Rubius

Физическая организация данных Файлы данных Можно распределять по разным дискам (в зависимости от сценария работы) Файл журнала транзакций Последовательная (sequential) запись Файлы резервных копий Full backup Incremental backup Log backup (для point-in-time restore)

Физическая организация данных в SQL Server БД SQL Server хранится в одном или нескольких файлах (.mdf, .ndf) Кроме файлов данных есть файл журнала транзакций (.ldf) Файл данных разбит на страницы по 8К Страница – минимальная единица чтения/записи данных Страницы сгруппированы в 64К экстенты Постраничная (поблочная) организация данных характерна для большинства реляционных СУБД

Организация данных на странице Страница с данными хранит записи таблицы Одна запись хранится на странице целиком (кроме LOB и var-типов, которые не влезли на страницу) Таким образом, при чтении всего одного атрибута, с диска считывается запись целиком (не считая LOB) Постраничная организация данных характерна для большинства реляционных СУБД

Дисковые операции Количество чтений/записей – это количество дисковых страниц Операции могут быть логические и физические

Организация данных на странице

Дисковые операции

Логарифмический поиск Чтобы найти данные в таблице по условию, необходимо выполнить сканирование таблицы – это O(N) Если данные отсортированы, то это можно сделать поиском за O(log(N))

Сбалансированные деревья

B-Tree Оптимизировано под страничную организацию данных во внешней памяти (один узел – одна страница) Сбалансированное (длина пути от корня до любого листа одинакова для всех листов) Логарифмический поиск (по количеству дисковых чтений) Логарифмическая запись Сильная ветвистость (сотни потомков у узла)

B-Tree

B-Tree

B-Tree

B-Tree

B-Tree

B-Tree

B-Tree

B-Tree

B-Tree

B-Tree

B-Tree

B-Tree

B-Tree Кластерный индекс Листовые узлы – страницы с данными Может быть только один для таблицы Некластерный индекс Листовые узлы – страницы с ключами, плюс ссылка на запись с данными Ссылка: значение ключа кластерного индекса (если он есть) адрес страницы с данными + идентификатор внутри страницы (если кластерный индекс отсутствует)

Когда использовать? СЕЛЕКТИВНОСТЬ! СЕЛЕКТИВНОСТЬ!

B*-Tree Индексы повышают эффективность Операции поиска записей с хорошей селективностью Поддержка уникальности значений атрибутов Операции, требующие упорядочивания по ключу (JOIN, DISTINCT) Проекция по небольшому количеству атрибутов

B-Tree Кластерный индекс лучше выбирать для атрибутов: Короткое значение ключа (т.к. ключи к.и. используются как ссылки в некластерных) Данные часто выбираются диапазонами значений ключа (т.к. по ключу к.и. сгруппированы записи в страницах данных) Чаще используются для поиска (т.к. нет дополнительного обращения к страницам данных, к.и. быстрее) По умолчанию индекс первичного ключа делается кластерным, но это не всегда оптимальный выбор

Пример

B-Tree

B*-Tree Included columns Можно построить индекс по нескольким атрибутам, а можно включить атрибуты посредством INCLUDE (и это не одно и то же) INCLUDED атрибуты не входят в состав ключа, но сохраняются в листьях Если запрос требует только атрибуты, входящие в индекс, либо в INCLUDED атрибуты индекса, то обращаться к странице с данными не придётся – нужные данные уже есть в индексе

B*-Tree FILLFACTOR Задаёт объём занятого пространства на листовых страницах, которое выделяет СУБД при создании/перестройке индекса По умолчанию – 100% Необходим для сокращения времени вставок/обновлений Несколько снижает скорость чтения

B*-Tree Фрагментация данных External fragmentation Internal fragmentation Способы дефрагментации: INDEX REORGANIZE INDEX REBUILD CREATE WITH DROP EXISTING Фрагментация – последнее, о чём стоит беспокоиться

Что почитать

Оптимизация запросов в реляционных БД Часть II Николай Александрович Шестаков Томский Политехнический Университет Rubius

Оптимизация и выполнение запроса Алгоритмы выполнения соединений Этапы жизненного цикла запроса План выполнения и выполнение запроса Кеширование планов выполнения

Join algorithms Nested loop join Inner join for each row R1 in outer table for each row R2 in inner table //or index lookup! if R1 joins with R2 return join (R1, R2) Outer join for each row R1 in outer table for each row R2 in inner table //or index lookup! if R1 joins with R2 return join (R1, R2) else return join (R1, NULL)

Join algorithms Merge join

Join algorithms Hash join

Join algorithms

Query optimization and execution Query Life Cycle

Query optimization and execution Optimization Goal – to find a good enough execution plan, quickly enough Phases Simplification Trivial plan search Statistics update Cost-based optimization (several stages here) Execution plan generation

Query optimization and execution Посмотреть план выполнения: Можно в Management Studio, включив опцию “Show execution plan” В текстовом/табличном/xml виде, предварительно выполнив запрос SET SHOWPLAN_TEXT ON или SET SHOWPLAN_ALL ON или SET SHOWPLAN_XML ON Использовать системную функцию sys.dm_exec_query_stats. В этом случае не нужно отдельно запускать запрос, план будет показан из кеша

План выполнения Estimated execution plan Actual execution plan

План выполнения Actual execution plan показывает не только оцениваемые показатели, но и реальные

План выполнения

План выполнения Планы можно выводить в виде: Графический XML Табличный (через SET STATISTICS PROFILE ON) Текстовый

Query optimization and execution Query execution

Query optimization and execution Query execution

Статистики /* drop table ForeignKeyTable drop table PrimaryTable */ create table PrimaryTable (Id int identity primary key, N int, S char(150)) go create table ForeignKeyTable (Id int identity primary key, IdPrimary int references PrimaryTable, N int, S char(150)) go insert into PrimaryTable (N, S) values (CAST(RAND() * 10000 as int), CAST(NEWID() as char(150))) go 100000 insert into ForeignKeyTable (IdPrimary, N, S) values (CAST(RAND() * 100000 as int), CAST(RAND() * 1000 as int), CAST(NEWID() as char(150))) go 200000 insert into ForeignKeyTable (IdPrimary, N, S) values (CAST(RAND() * 100000 as int), CAST(RAND() * 1000 + 1000 as int), CAST(NEWID() as char(150))) go 100000 insert into ForeignKeyTable (IdPrimary, N, S) values (CAST(RAND() * 100000 as int), CAST(RAND() * 1000 + 2000 as int), CAST(NEWID() as char(150))) go 150000 create nonclustered index IX_ForeignKeyTable ON dbo.ForeignKeyTable(N) go select * from PrimaryTable p join ForeignKeyTable f on p.Id = f.IdPrimary where f.N = 1234 -- change selectivity here and see how execution plan is changing DBCC SHOW_STATISTICS ("dbo.ForeignKeyTable", "IX_ForeignKeyTable")

Статистики

Статистики

Статистики

Статистики Статистики обновляются автоматически Иногда эвристики автообновления не срабатывают Тогда нужно обновить вручную Если Actual Rows = Estimated Rows – статистики ни при чём

Кеширование планов выполнения Планы кешируются Разные значения параметров –> один кеш Parameter Sniffing OPTIMIZE FOR UNKNOWN hint

Query optimization and execution Просмотр кешированных планов выполнения

Что почитать

Транзакции ACID Atomicity Consistency Isolation Durability

Транзакции Atomicity – всё или ничего

Транзакции Durability – если транзакция выполнена, она выполнена (результат устойчив к системным сбоям)

Транзакции Consistency Данные согласованы в начале транзакции и после окончания транзакции (но не обязательно внутри транзакции) Согласованные данные – удовлетворяющие ограничениям целостности и бизнес-правилам Иногда свойство понимают в том смысле, что результаты завершённых транзакций должны быть видны последующим транзакциям

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

Уровни изоляции транзакций Read Uncommitted Разрешены грязные чтения Read Committed Чтения только зафиксированных данных, но повторное чтение может вернуть изменённые данные Repeatable Read Повторное чтение внутри транзакции всегда возвращает одинаковые данные для прочитанных ранее записей. Но могут появиться новые записи, которых раньше не было Serializable Полная сериализация! Snapshot Используется мультиверсионность записей, каждая транзакция видит состояние БД, которое было на момент её начала

Уровни изоляции транзакций Read Uncommitted Быстр Никого не ждёт Наибольшая вероятность получить несогласованные данные При чтении ничего не блокирует

Уровни изоляции транзакций Read Committed Ждёт освобождения exclusive lock Есть вероятность получить изменённые данные при повторных чтениях При чтении ничего не блокирует

Уровни изоляции транзакций Repeatable Read Ждёт освобождения exclusive lock При чтении ставит Shared lock При повторных чтениях могут появляться фантомные записи

Уровни изоляции транзакций Serializable Обеспечивает 100% изоляцию Ждёт освобождения exclusive lock При чтении ставит Shared lock на диапазон значений атрибутов (диапазон берётся из условия запроса)

Locks Shared Lock Блокирует изменение (попытки Update и Exclusive), позволяет чтение. Несколько транзакций могут установить одновременно на один ресурс. Exclusive Lock Блокирует изменение (попытки Update и Exclusive) и чтение. Только одна транзакция может установить одновременно на один ресурс. Запрашивается для изменения данных. Key-Range Запрещает INSERT по значениям диапазона ключей Update Lock Блокирует изменение (попытки Update и Exclusive), позволяет чтение. Только одна транзакция может установить одновременно на один ресурс. Потом для обновления записи запрашивается Exclusive. Intent Lock, Schema Lock, Bulk Update Lock

Deadlocks Вероятность взаимных блокировок повышается, если: Большое количество параллельных транзакций, которые меняют данные Используются долгие сложные транзакции, состоящие из нескольких операций Используются операции, блокирующие большое количество записей (агрегатные, типа SUM) Используется высокий уровень изоляции Не используется MVCC (Snapshot Isolation)

Snapshot Isolation Multiversion Concurrency Control Используется timestamp для обозначения версии записи Транзакции читают версии записей, соответствующие моменту начала транзакции При изменении данных, старые записи перемещаются в хранилище Version Store (в tempdb) В SQL Server включается для БД целиком: SET READ_COMMITTED_SNAPSHOT ON или SET ALLOW_SNAPSHOT_ISOLATION ON Snapshot Isolation исключает аномалии грязных, повторных и фантомных чтений Отсутствуют блокировки при чтении Snapshot Isolation не обеспечивает Serializable «Serializable» в Oracle – на самом деле Snapshot!

Snapshot Isolation Snapshot Isolation исключает аномалии грязных, повторных и фантомных чтений Отсутствуют блокировки при чтении Snapshot Isolation не обеспечивает Serializable «Serializable» в Oracle – на самом деле Snapshot! (аналогично в PostgreSQL < 9.1) MVCC режим выгоден при большом количестве параллельных транзакций, но требует ресурсов на управление версиями данных

Snapshot Isolation write-skew anomaly

Monitoring locks and deadlocks SSMS Activity Monitor Performance Monitor SQL Server Lock counters Dynamic Management Views sys.dm_exec_requests sys.dm_tran_locks sys.dm_os_waiting_tasks SQL Server Profiler SQL Server Extended Events (since 2012) http://www.brentozar.com/archive/2014/04/introduction-extended-events/ http://www.mssqltips.com/sqlservertip/2732/different-techniques-to-identify-blocking-in-sql-server/ http://www.brentozar.com/archive/2014/06/capturing-deadlock-information/