ОПТИМИЗАЦИИ СКОРОСТИ
ВЫПОЛНЕНИЯ ЗАПРОСОВ В РСУБД
КОМУ И КОГДА НУЖНА ОПТИМИЗАЦИЯ?
КАК МОЖНО ОПТИМИЗИРОВАТЬ СКОРОСТЬ
ВЫПОЛНЕНИЯ
 На уровне запросов
 На уровне схемы
 На уровне системы
УРОВЕНЬ ЗАПРОСОВ
 Выполнение запроса
 Чтение планов выполнения
 Управления планами выполнения
 Типичные ошибки
ВЫПОЛНЕНИЕ ЗАПРОСА
ЧТЕНИЕ ПЛАНОВ ВЫПОЛНЕНИЯ (MYSQL)
 EXPLAIN - ориентировочный план выполнения
 SHOW STATUS - показывает непосредственно
чт...
SHOW STATUS
 FLUSH STATUS
 …
 SHOW STATUS LIKE 'Key_read%';
 Key_read_requests — Количество запросов на
чтение индексн...
PROFILING
 set profiling=1;
 …
 show profiles;
 select sum(duration) from
information_schema.profiling where
query_id=...
ЧТЕНИЕ ПЛАНОВ MYSQL
 EXPLAIN
 Id - Идентификатор (ID) таблицы в запросе. EXPLAIN создает по
одной записи для каждой табл...
ЧТЕНИЕ ПЛАНОВ ВЫПОЛНЕНИЯ
(POSTGRESQL)
 EXPLAIN – предположительный план
выполнения
 EXPLAIN ANALYZE – реальный план
выпо...
EXPLAIN (POSTGRESQL)
 explain select attname
from pg_attribute, pg_class
where pg_attribute.attrelid = pg_class.oid
and p...
УПРАВЛЕНИЯ ПЛАНАМИ ВЫПОЛНЕНИЯ
 Использование правильного индекса
 Запретить использование неподходящего
индекса
 Подска...
ИСПОЛЬЗОВАНИЕ ПРАВИЛЬНОГО ИНДЕКСА
Таблица.ВедущийСтолбецИндекса = Выражение
 Селективное условие по ведущему столбцу
инде...
ЗАПРЕТИТЬ ИСПОЛЬЗОВАНИЕ
НЕПОДХОДЯЩЕГО ИНДЕКСА
 Создать простейшее выражение при
упоминании индексируемого столбца:
O.Regi...
ЗАПРЕТ СОЕДИНЕНИЯ В НЕПРАВИЛЬНОМ
ПОРЯДКЕ
 Запрещение использования индекса
 Использование внешних соединений
SELECT … FR...
ЗАПРЕТ СОЕДИНЕНИЯ В НЕПРАВИЛЬНОМ
ПОРЯДКЕ
 Зависимости соединений.
… AND T1.Key2 = T2.Key2
AND T1.Key3 + 0*T2.Key2 = T3.Ke...
С ЧЕГО НАЧАТЬ?
 --log-slow-queries
 логирование медленных запросов,
 минимальное значение параметра long_query_time 1,
...
ОШИБКИ (DESIGN )
 Сначала нормализуем, потом денормализуем
где необходимо.
 Старайтесь всегда создать поле ID.
 Индекси...
ОШИБКИ (SQL)
 Используйте Prepared Statements
 Не используйте DISTINCT если вы используете
GROUP BY
 LIMIT m,n не так б...
ОШИБКИ
 По возможности не используйте SELECT *
 SQL_NO_CACHE когда вы делаете SELECT для
часто обновляемого набора данны...
КОНКРЕТНЫЕ ЗАПРОСЫ
 SELECT max(...)/min(...) FROM <big table>
 SELECT field FROM foo ORDER BY field DESC LIMIT
1;
 Pagi...
НА УРОВНЕ СХЕМЫ
 НормализацияДенормализация
 БлокировкиТранзакции
 Типы таблиц
 Views
 Temporary Tables
 Indexes
 Т...
ТИПЫ ТАБЛИЦ
 ISAM - Оригинальный обработчик таблиц.
 MyISAM - Новый обработчик, обеспечивающий
переносимость таблиц в би...
VIEWS
 CREATE [ALGORITHM = {UNDEFINED | MERGE |
TEMPTABLE}] VIEW
 MERGE – при обращении к представлению
добавляет в испо...
INDEXES
 B-/B+ tree
 R-/R+ tree
 Hash
 Expression
 Partial
 Reverse
 Bitmap
 GiST
 GIN
 Кластерные - строки табл...
B-ДЕРЕВЬЯ
Логическое представление -
сбалансированное сильно
ветвистое дерево во внешней
памяти.
Физической организации B-...
R-ДЕРЕВО
Подобно B-дереву, но
используется для организации
доступа к пространственным
данным, то есть для
индексации много...
HASH
 They are used only for equality comparisons that
use the = or <=> operators (but are very fast)
 The optimizer can...
EXPRESSION & PARTIAL & REVERSE
 Expression
 SELECT * FROM people WHERE
(first_name || ' ' || last_name) = 'John Smith';
...
BITMAP
 для данных с малой мощностью множества
(cardinality)
GIST (GENERALIZED SEARCH TREE)
 представляет собой систему, объединяющую
большой набор различных алгоритмов сортировки и
...
GIST (GENERALIZED SEARCH TREE)
 Стандарные методы навигации по дереву
 Обновление дерева
 Конкурентность и восстановлен...
GIN (GENERALIZED INVERTED INDEX)
 Поддерживает разные типы данных
 Очень быстрый поиск по ключам — Btree
 Поддержка par...
ПРИЛОЖЕНИЯ (GIST, GIN)
 Целочисленные массивы (GiST, GIN)
 Полнотекстовый поиск (GiST, GIN)
 Данные с древовидной струк...
СРАВНЕНИЕ
MySQL Oracle PostgreSQL HSQLDB SQLite
B-/B+ tree
R-/R+ tree
Hash
Expression
Partial
Reverse
Bitmap
GiST
GIN
RDBMS
ТРИГЕРЫ
 CREATE TRIGGER trigger_name trigger_time
trigger_event ON tbl_name FOR EACH ROW
trigger_stmt
 trigger_time
 BE...
ДРУГИЕ
 НормализацияДенормализация
 Большое количество соединений таблиц
 Расчетные значения
 Длинные поля
 Temporary...
НА УРОВНЕ СИСТЕМЫ
 Наиболее важно настроить потребление
памяти
Нельзя забывать, что РСУБД такое же
приложение как и все о...
ЛИТЕРАТУРА
 SQL Tuning. Dan Tow
 High Performance MySQL. Baron Schwartz, Peter
Zaitsev, Vadim Tkachenko, Jeremy D.
Zawod...
Upcoming SlideShare
Loading in …5
×

Оптимизации скорости выполнения запросов

984 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
984
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Оптимизации скорости выполнения запросов

  1. 1. ОПТИМИЗАЦИИ СКОРОСТИ ВЫПОЛНЕНИЯ ЗАПРОСОВ В РСУБД
  2. 2. КОМУ И КОГДА НУЖНА ОПТИМИЗАЦИЯ?
  3. 3. КАК МОЖНО ОПТИМИЗИРОВАТЬ СКОРОСТЬ ВЫПОЛНЕНИЯ  На уровне запросов  На уровне схемы  На уровне системы
  4. 4. УРОВЕНЬ ЗАПРОСОВ  Выполнение запроса  Чтение планов выполнения  Управления планами выполнения  Типичные ошибки
  5. 5. ВЫПОЛНЕНИЕ ЗАПРОСА
  6. 6. ЧТЕНИЕ ПЛАНОВ ВЫПОЛНЕНИЯ (MYSQL)  EXPLAIN - ориентировочный план выполнения  SHOW STATUS - показывает непосредственно что произошло после выполнения запроса, т.е. количество записей, к которым MySQL физически обратился (притом посредством данной команды можно узнать сколько из них было получено из памяти, а сколько посредством обращения к диску  PROFILING - возможность профайлинга запросов  PROCEDURE ANALYSE() – подсказки по оптимизации
  7. 7. SHOW STATUS  FLUSH STATUS  …  SHOW STATUS LIKE 'Key_read%';  Key_read_requests — Количество запросов на чтение индексных блоков из кеша.  Key_reads — Количество физического чтения индексных блоков с диска. Если число Key_reads большое, тогда, вероятно, ваше key_buffer_size достаточно мало и требует увеличения. Отношение непопаданий в кэш можно посчитать как Key_reads/Key_read_requests.
  8. 8. PROFILING  set profiling=1;  …  show profiles;  select sum(duration) from information_schema.profiling where query_id=1;  show profile for query 1;
  9. 9. ЧТЕНИЕ ПЛАНОВ MYSQL  EXPLAIN  Id - Идентификатор (ID) таблицы в запросе. EXPLAIN создает по одной записи для каждой таблицы в запросе.  Select_type - Возможные значения: SIMPLE, PRIMARY, UNION, DEPENDENT UNION, SUBSELECT, и DERIVED.  Table - Имя таблицы, из которой MySQL читает данные  Type - Тип объединения, которое использует MySQL. Возможные значения: eq_ref, ref, range, index, или all.  Possible_keys – Список индексов (или NULL, если индексов нет), которые MySQL может использовать для выборки рядов в таблице.  Key - Название индекса, который использует MySQL (после проверки всех возможных индексов).  Key_len - Размер ключа в байтах.  Ref - Колонки или значения, которые используются для сравнения с ключем.  Rows - Количество рядов, которые MySQL необходимо проверить, для обработки запроса.  Extra - Дополнительная информация о запросе.
  10. 10. ЧТЕНИЕ ПЛАНОВ ВЫПОЛНЕНИЯ (POSTGRESQL)  EXPLAIN – предположительный план выполнения  EXPLAIN ANALYZE – реальный план выполнения, выводиться после выполнения запроса  ANALYZE – собрать статистику  VACUUM - дефрагментация  REINDEX
  11. 11. EXPLAIN (POSTGRESQL)  explain select attname from pg_attribute, pg_class where pg_attribute.attrelid = pg_class.oid and pg_class.relname = ’pg_proc’ order by pg_attribute.attnum; Sort (cost=27.66..27.68 rows=7 width=66) Sort Key: pg_attribute.attnum -> Nested Loop (cost=0.00..27.56 rows=7 width=66) -> Index Scan using pg_class_relname_nsp_index on pg_class (cost=0.00..8.27 rows=1 width=4) Index Cond: (relname = ’pg_proc’::name) -> Index Scan using pg_attribute_relid_attnum_index on pg_attribute (cost=0.00..19.21 rows=7 width=70) Index Cond: (pg_attribute.attrelid = pg_class.oid)
  12. 12. УПРАВЛЕНИЯ ПЛАНАМИ ВЫПОЛНЕНИЯ  Использование правильного индекса  Запретить использование неподходящего индекса  Подсказки для оптимизатора  Запрет Соединения в неправильном порядке  Подсказки
  13. 13. ИСПОЛЬЗОВАНИЕ ПРАВИЛЬНОГО ИНДЕКСА Таблица.ВедущийСтолбецИндекса = Выражение  Селективное условие по ведущему столбцу индекса. Условие должно быть таким чтобы БД могла выделить достаточно узкий диапазон.  Преобразование типов (условие в запросе и поле должны использовать один тип данных)  Условия соединены оператором OR  В условии присутствуют функции от ведущего столбца индекса.
  14. 14. ЗАПРЕТИТЬ ИСПОЛЬЗОВАНИЕ НЕПОДХОДЯЩЕГО ИНДЕКСА  Создать простейшее выражение при упоминании индексируемого столбца: O.Regino_ID + 0 = 137  Подсказки:  table_name [[AS] alias] [index_hint]  USE INDEX (index_list)  GNORE INDEX (index_list)  FORCE INDEX (index_list)
  15. 15. ЗАПРЕТ СОЕДИНЕНИЯ В НЕПРАВИЛЬНОМ ПОРЯДКЕ  Запрещение использования индекса  Использование внешних соединений SELECT … FROM employees E LEFT OUTER JOIN location L ON E.location_id = L.id  Отсутствие избыточных условий соединения SELECT … FROM employees E, locations L, addresses A WERE E.location_id = L.id AND E.location_id = A.id AND A.zip_code = 95628
  16. 16. ЗАПРЕТ СОЕДИНЕНИЯ В НЕПРАВИЛЬНОМ ПОРЯДКЕ  Зависимости соединений. … AND T1.Key2 = T2.Key2 AND T1.Key3 + 0*T2.Key2 = T3.Key3 …  STRAIGHT_JOIN – тоже что и JOIN, только левая таблица всегда читается до правой.
  17. 17. С ЧЕГО НАЧАТЬ?  --log-slow-queries  логирование медленных запросов,  минимальное значение параметра long_query_time 1,  значение по умолчанию 10  --log-queries-not-using-indexes  логирование запросов, которые не используют индексы
  18. 18. ОШИБКИ (DESIGN )  Сначала нормализуем, потом денормализуем где необходимо.  Старайтесь всегда создать поле ID.  Индексируйте поля, по которым ищите.  Индексируйте поля для объединения и используйте для них одинаковые типы столбцов.  Не индексируйте все что попало!  Не включайте в индекс большие колонки.  Не дублируйте индексы  Используйте NOT NULL, если это возможно
  19. 19. ОШИБКИ (SQL)  Используйте Prepared Statements  Не используйте DISTINCT если вы используете GROUP BY  LIMIT m,n не так быстр как кажется  По возможности заменяйте OR на UNION  GROUP BY … ORDER BY NULL  UNION и UNION ALL две разные операции и чаще всего вам нужно второе  Минимизируйте коррелируемымые подзапросы
  20. 20. ОШИБКИ  По возможности не используйте SELECT *  SQL_NO_CACHE когда вы делаете SELECT для часто обновляемого набора данных  Не используйте ORDER BY RAND()  LIMIT 1, когда нужна единственная строка  SELECT * FROM user WHERE state = 'Alabama' LIMIT 1  Используйте ENUM вместо VARCHAR
  21. 21. КОНКРЕТНЫЕ ЗАПРОСЫ  SELECT max(...)/min(...) FROM <big table>  SELECT field FROM foo ORDER BY field DESC LIMIT 1;  Pagination  WHERE … AND NODE_ID > id_from_previous_page ORDER BY NODE_ID LIMIT 25  SELECT count(*) FROM <big table>  лучше так и использовать
  22. 22. НА УРОВНЕ СХЕМЫ  НормализацияДенормализация  БлокировкиТранзакции  Типы таблиц  Views  Temporary Tables  Indexes  Тригеры
  23. 23. ТИПЫ ТАБЛИЦ  ISAM - Оригинальный обработчик таблиц.  MyISAM - Новый обработчик, обеспечивающий переносимость таблиц в бинарном виде, который заменяет ISAM  BDB – (Berkley DB) Таблицы с поддержкой транзакций и блокировкой страниц.  InnoDB - Таблицы с поддержкой транзакций и блокировкой строк  MERGE - Набор таблиц MyISAM, используемый как одна таблица.  HEAP - Данные для этой таблицы хранятся только в памяти
  24. 24. VIEWS  CREATE [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] VIEW  MERGE – при обращении к представлению добавляет в использующийся оператор соответствующие части из определения представления и выполняет получившийся оператор  TEMPTABLE - заносит содержимое представления во временную таблицу, над которой затем выполняется оператор обращенный к представлению
  25. 25. INDEXES  B-/B+ tree  R-/R+ tree  Hash  Expression  Partial  Reverse  Bitmap  GiST  GIN  Кластерные - строки таблицы физически хранятся в заданном порядке и непосредственно связаны с элементами индекса, благодаря чему значительно ускоряется доступ к данным при использовании запросов, использующих данный индекс  Некластерные
  26. 26. B-ДЕРЕВЬЯ Логическое представление - сбалансированное сильно ветвистое дерево во внешней памяти. Физической организации B- дерево представляется как мультисписочная структура страниц внешней памяти.
  27. 27. R-ДЕРЕВО Подобно B-дереву, но используется для организации доступа к пространственным данным, то есть для индексации многомерной информации, такой, например , как географические данные
  28. 28. HASH  They are used only for equality comparisons that use the = or <=> operators (but are very fast)  The optimizer cannot use a hash index to speed up ORDER BY operations  This may affect some queries if you change a MyISAM table to a hash-indexed MEMORY table.  Only whole keys can be used to search for a row.
  29. 29. EXPRESSION & PARTIAL & REVERSE  Expression  SELECT * FROM people WHERE (first_name || ' ' || last_name) = 'John Smith';  CREATE INDEX people_names ON people ((first_name || ' ' || last_name));  Partial  SELECT * FROM scheta WHERE NOT uplocheno AND ...;  CREATE INDEX scheta_neuplocheno ON scheta (id) WHERE NOT uplocheno;  Reverse  обращает поле переменной — первый символ считается последним  24538 -> 83542
  30. 30. BITMAP  для данных с малой мощностью множества (cardinality)
  31. 31. GIST (GENERALIZED SEARCH TREE)  представляет собой систему, объединяющую большой набор различных алгоритмов сортировки и поиска, включая B-деревья, B+-деревья, R- деревья, деревья частичных сумм, ранжированные B+-деревья, и другие. Она также обеспечивает интерфейс, обеспечивающий как создание пользовательских типов данных, так и расширенные методы запросов, позволяющие выполнять поиск по ним. Т.е. GiST дает возможность определить, что вы храните, как вы это храните, и каким образом вы будете выполнять поиск. Эти возможности существенно превышают средства, даваемые стандартными алгоритмами типа B-дерева или R- дерева.
  32. 32. GIST (GENERALIZED SEARCH TREE)  Стандарные методы навигации по дереву  Обновление дерева  Конкурентность и восстановление после сбоя  GiST позволяет реализовать новый АМ эксперту в области данных  Поддерживает расширяемый набор запросов ( в отличие от Btree)  Новые типы данных обладают производительностью (индексный доступ, конкурентность) и надежностью (протокол логирования), как и встроенные типы
  33. 33. GIN (GENERALIZED INVERTED INDEX)  Поддерживает разные типы данных  Очень быстрый поиск по ключам — Btree  Поддержка partial match  Многоатрибутный индекс  Хорошая масштабируемость (кол-во ключей, кол-во документов)  Быстрое создание индекса  Медленное обновление индекса :(  Надежность и хороший параллелизм
  34. 34. ПРИЛОЖЕНИЯ (GIST, GIN)  Целочисленные массивы (GiST, GIN)  Полнотекстовый поиск (GiST, GIN)  Данные с древовидной структурой (GiST)  Поиск похожих слов (GiST, GIN)  Rtree (GiST)  PostGIS (postgis.org) (GiST) — spatial index  BLASTgres (GiST) — биоинформатика  Многомерный куб (GiST)  ........
  35. 35. СРАВНЕНИЕ MySQL Oracle PostgreSQL HSQLDB SQLite B-/B+ tree R-/R+ tree Hash Expression Partial Reverse Bitmap GiST GIN
  36. 36. RDBMS
  37. 37. ТРИГЕРЫ  CREATE TRIGGER trigger_name trigger_time trigger_event ON tbl_name FOR EACH ROW trigger_stmt  trigger_time  BEFORE  AFTER  trigger_event  Insert (insert, data load, replace)  Update (update)  Delete (delete, replace)
  38. 38. ДРУГИЕ  НормализацияДенормализация  Большое количество соединений таблиц  Расчетные значения  Длинные поля  Temporary table  CREATE [TEMPORARY] TABLE …  БлокировкиТранзакции
  39. 39. НА УРОВНЕ СИСТЕМЫ  Наиболее важно настроить потребление памяти Нельзя забывать, что РСУБД такое же приложение как и все остальные на сервере. И чаще всего оно использует файловую систему операционной системы, у которой есть свои КЭШи.  OPTIMIZE TABLE имя_таблицы; Почистить "дырки" (дефрагментация), обновить статистику и отсортировать индексы.  ANALYZE TABLE имя_таблицы; Апдейт статистики оптимизатора.
  40. 40. ЛИТЕРАТУРА  SQL Tuning. Dan Tow  High Performance MySQL. Baron Schwartz, Peter Zaitsev, Vadim Tkachenko, Jeremy D. Zawodny, Arjen Lentz,and Derek J. Balling  www.mysql.ru  www.phpclub.ru  http://dev.mysql.com/doc/refman  http://www.mysqlperformanceblog.com  http://highload.ru

×