Query perfomance tuning

Оптимизации скорости выполнения запросов в РСУБД

Кому и когда нужна оптимизация?

Как можно оптимизировать скорость выполнения На уровне запросовНа уровне схемыНа уровне системы

УровеньзапросовВыполнение запросаЧтение планов выполненияУправления планами выполненияТипичные ошибки

Выполнение запроса

Чтение планов выполнения (MySQL)EXPLAIN - ориентировочный план выполненияSHOW STATUS - показывает непосредственно что произошло после выполнения запроса, т.е. количество записей, к которым MySQL физически обратился (притом посредством данной команды можно узнать сколько из них было получено из памяти, а сколько посредством обращения к дискуPROFILING - возможность профайлингазапросовPROCEDURE ANALYSE() – подсказки по оптимизации

SHOW STATUSFLUSH STATUS…SHOW STATUS LIKE 'Key_read%';Key_read_requests — Количество запросов на чтение индексных блоков из кеша.Key_reads — Количество физического чтения индексных блоков с диска. Если число Key_reads большое, тогда, вероятно, ваше key_buffer_size достаточно мало и требует увеличения. Отношение непопаданий в кэш можно посчитать как Key_reads/Key_read_requests.

PROFILINGset profiling=1;…show profiles;select sum(duration) from information_schema.profiling where query_id=1;show profile for query 1;

Чтение плановMySQLEXPLAINId - Идентификатор (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 - Дополнительная информация о запросе.

Чтение планов выполнения (PostgreSQL)EXPLAIN – предположительный план выполненияEXPLAIN ANALYZE – реальный план выполнения, выводиться после выполнения запросаANALYZE – собрать статистикуVACUUM - дефрагментацияREINDEX

EXPLAIN(PostgreSQL)explain select attnamefrompg_attribute, pg_classwherepg_attribute.attrelid = pg_class.oid andpg_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 onpg_attribute (cost=0.00..19.21 rows=7 width=70)Index Cond: (pg_attribute.attrelid = pg_class.oid)

Управления планами выполненияИспользование правильного индексаЗапретить использование неподходящего индексаПодсказки для оптимизатораЗапрет Соединения в неправильном порядкеПодсказки

Использование правильного индексаТаблица.ВедущийСтолбецИндекса = ВыражениеСелективное условие по ведущему столбцу индекса. Условие должно быть таким чтобы БД могла выделить достаточно узкий диапазон.Преобразование типов (условие в запросе и поле должны использовать один тип данных)Условия соединены оператором ORВ условии присутствуют функции от ведущего столбца индекса.

Запретить использование неподходящего индексаСоздать простейшее выражение при упоминании индексируемого столбца:O.Regino_ID+ 0 = 137Подсказки:table_name[[AS] alias] [index_hint] USE INDEX (index_list) GNORE INDEX (index_list) FORCE INDEX(index_list)

Запрет Соединения в неправильном порядкеЗапрещение использования индексаИспользование внешних соединений SELECT … FROM employees E LEFT OUTER JOIN location L ON E.location_id = L.idОтсутствие избыточных условий соединенияSELECT … FROM employees E, locations L, addresses AWERE E.location_id = L.id AND E.location_id = A.id AND A.zip_code = 95628

Запрет Соединения в неправильном порядкеЗависимости соединений.… AND T1.Key2 = T2.Key2 AND T1.Key3 + 0*T2.Key2 = T3.Key3 …STRAIGHT_JOIN – тоже что и JOIN, только левая таблица всегда читается до правой.

С чего начать?--log-slow-queriesлогирование медленных запросов, минимальное значение параметра long_query_time 1, значение по умолчанию 10--log-queries-not-using-indexesлогирование запросов, которые не используют индексы

Ошибки (Design )Сначала нормализуем, потом денормализуем где необходимо. Старайтесь всегда создать поле ID.Индексируйте поля, по которым ищите.Индексируйте поля для объединения и используйте для них одинаковые типы столбцов.Не индексируйте все что попало!Не включайте в индекс большие колонки.Не дублируйте индексыИспользуйте NOT NULL, если это возможно

Ошибки (SQL) Используйте Prepared StatementsНе используйтеDISTINCT если вы используетеGROUP BY LIMIT m,nне так быстр как кажетсяПо возможности заменяйте OR на UNIONGROUP BY …ORDER BY NULLUNION и UNION ALL две разные операции и чаще всего вам нужно второеМинимизируйте коррелируемымыеподзапросы

ОшибкиПо возможности не используйте SELECT *SQL_NO_CACHE когда вы делаете SELECT для часто обновляемого набора данныхНе используйте ORDER BY RAND()LIMIT 1, когда нужна единственная строкаSELECT * FROM user WHERE state = 'Alabama' LIMIT 1Используйте ENUM вместо VARCHAR

Конкретные запросыSELECT max(...)/min(...) FROM <big table>SELECT field FROM foo ORDER BY field DESC LIMIT 1;PaginationWHERE … AND NODE_ID > id_from_previous_page ORDER BY NODE_ID LIMIT 25SELECT count(*) FROM <big table>лучше так и использовать

На уровне схемыНормализация\ДенормализацияБлокировки\ТранзакцииТипы таблицViewsTemporary TablesIndexesТригеры

Типы таблицISAM - Оригинальный обработчик таблиц. MyISAM - Новый обработчик, обеспечивающий переносимость таблиц в бинарном виде, который заменяет ISAMBDB – (Berkley DB) Таблицы с поддержкой транзакций и блокировкой страниц.InnoDB - Таблицы с поддержкой транзакций и блокировкой строкMERGE - Набор таблиц MyISAM, используемый как одна таблица.HEAP - Данные для этой таблицы хранятся только в памяти

ViewsCREATE [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}] VIEWMERGE – при обращении к представлению добавляет в использующийся оператор соответствующие части из определения представления и выполняет получившийся операторTEMPTABLE - заносит содержимое представления во временную таблицу, над которой затем выполняется оператор обращенный к представлению

IndexesB-/B+ treeR-/R+ treeHashExpressionPartialReverse Bitmap GiST GIN Кластерные - строки таблицы физически хранятся в заданном порядке и непосредственно связаны с элементами индекса, благодаря чему значительно ускоряется доступ к данным при использовании запросов, использующих данный индексНекластерные

B-деревьяЛогическое представление - сбалансированное сильно ветвистое дерево во внешней памяти.Физической организации B-дерево представляется как мультисписочная структура страниц внешней памяти.

R-деревоПодобно B-дереву, но используется для организации доступа к пространственным данным, то есть для индексации многомерной информации, такой, например, как географические данные

HashThey 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 operationsThis 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.

Expression & Partial & ReverseExpression SELECT * FROM people WHERE (first_name || ' ' || last_name) = 'John Smith';CREATE INDEX people_names ON people ((first_name || ' ' || last_name));PartialSELECT * FROM scheta WHERE NOT uplocheno AND ...;CREATE INDEX scheta_neuplocheno ON scheta (id) WHERE NOT uplocheno; Reverseобращает поле переменной — первый символ считается последним24538 -> 83542

Bitmap для данных с малой мощностьюмножества (cardinality)

GiST (Generalized Search Tree)представляет собой систему, объединяющую большой набор различных алгоритмов сортировки и поиска, включая B-деревья, B+-деревья, R-деревья, деревья частичных сумм, ранжированные B+-деревья, и другие. Она также обеспечивает интерфейс, обеспечивающий как создание пользовательских типов данных, так и расширенные методы запросов, позволяющие выполнять поиск по ним. Т.е. GiST дает возможность определить, что вы храните, как вы это храните, и каким образом вы будете выполнять поиск. Эти возможности существенно превышают средства, даваемые стандартными алгоритмами типа B-дерева или R-дерева.

GiST (Generalized Search Tree)Стандарныеметоды навигации по деревуОбновление дереваКонкурентностьи восстановление после сбояGiSTпозволяет реализовать новый АМ эксперту в области данныхПоддерживает расширяемый набор запросов ( в отличие от Btree)Новые типы данных обладают производительностью (индексный доступ, конкурентность) и надежностью (протокол логирования), как и встроенные типы

GIN(Generalized Inverted Index)Поддерживает разные типы данныхОчень быстрый поиск по ключам — BtreeПоддержка partial matchМногоатрибутныйиндексХорошая масштабируемость (кол-во ключей, кол-во документов)Быстрое создание индексаМедленное обновление индекса :(Надежность и хороший параллелизм

Приложения (GiST, GIN)Целочисленные массивы (GiST, GIN)Полнотекстовый поиск (GiST, GIN)Данные с древовидной структурой (GiST)Поиск похожих слов (GiST, GIN)Rtree(GiST)PostGIS(postgis.org) (GiST) — spatial indexBLASTgres(GiST) — биоинформатикаМногомерный куб (GiST)........

ТригерыCREATE TRIGGER trigger_nametrigger_timetrigger_eventON tbl_name FOR EACH ROW trigger_stmttrigger_timeBEFORE AFTERtrigger_eventInsert (insert, data load, replace)Update (update)Delete (delete, replace)

ДругиеНормализация\ДенормализацияБольшое количество соединений таблицРасчетные значенияДлинные поляTemporarytableCREATE [TEMPORARY] TABLE …Блокировки\Транзакции

На уровне системыНаиболее важно настроить потребление памятиНельзя забывать, что РСУБД такое же приложение как и все остальные на сервере. И чаще всего оно использует файловую систему операционной системы, у которой есть свои КЭШи. OPTIMIZE TABLE имя_таблицы; Почистить "дырки" (дефрагментация), обновить статистику и отсортировать индексы. ANALYZE TABLE имя_таблицы;Апдейт статистики оптимизатора.

ЛитератураSQL Tuning. Dan TowHigh Performance MySQL. Baron Schwartz, Peter Zaitsev, VadimTkachenko, Jeremy D. Zawodny, ArjenLentz,andDerek J. Ballingwww.mysql.ruwww.phpclub.ruhttp://dev.mysql.com/doc/refmanhttp://www.mysqlperformanceblog.comhttp://highload.ru

Query perfomance tuning

More Related Content

What's hot (20)

Viewers also liked (7)

Similar to Query perfomance tuning (20)

Query perfomance tuning