Аннотация: В этой статье рассказывается о нашем понимании оптимизации базы данных с точки зрения процесса выполнения SQL, плана выполнения, структуры данных индекса, принципа ускорения запроса индекса, сфокусированного индекса, принципа оптимизации левого префикса и индекса первичного ключа с автоинкрементом.
Эта статья опубликована в сообществе Huawei Cloud « Обзор опыта оптимизации производительности баз данных в инженерных приложениях », автор: Ye Gong.
1. Введение
Большинство продуктов алгоритмов, поставляемых на этом этапе, включают использование баз данных. Контент, который он несет, включает в себя: управление правами пользователей, информацию о наборах данных, результаты асинхронного вывода, персонализированную конфигурацию и т. д.
В сценарии OCR совокупный объем данных обычно велик (сотни тысяч изображений в наборе данных), а база данных часто развертывается в общей базе данных клиента (одновременно работает большое количество других предприятий). и даже могут использовать один и тот же сервер только с зеркалом алгоритма, поэтому особое внимание следует уделять узким местам производительности базы данных в фоновых исследованиях и разработках.
В этой статье рассказывается о нашем понимании оптимизации базы данных с точки зрения процесса выполнения SQL, плана выполнения, структуры данных индекса, принципа ускорения запроса индекса, сфокусированного индекса, принципа оптимизации левого префикса и индекса первичного ключа с автоинкрементом.
2. Как получить полный оператор SQL в сценарии ORM
1. Онлайн-среда может перехватывать медленный SQL через пул соединений и выдавать тревожное уведомление.
2. На этапе тестирования, если полный SQL не может быть получен из-за использования предварительно скомпилированных операторов или структур ORM, вы можете использовать метод журнала базы данных для получения
set global general_log=on;
show variables where Variable_name="general_log_file"；2.1 Процесс выполнения SQL
Анализатор: анализировать SQL, какие таблицы нужно использовать, какие условия использовать (знать, что делать)
Оптимизатор: Выполните оценку производительности различных процессов выполнения и выберите процесс выполнения с наименьшими затратами. Стоимость - это только то, что думает оптимизатор, и это может быть неправильно (как сделать это быстрее всего)
Исполнитель: вызов интерфейса движка, возврат данных, движок подключаемый, аналог полиморфизма в программировании, можно выбрать соответствующий движок хранения при создании таблицы
2.2 План выполнения
Добавьте ключевое слово объяснения перед SQL, чтобы получить план выполнения SQL.По плану выполнения вы можете судить, соответствует ли процесс выполнения ожиданиям.
explain
SELECT
db_dataset.uuid AS db_dataset_uuid,
db_dataset.NAME AS db_dataset_name,
db_dataset.updated_at AS db_dataset_updated_at,
db_dataset.created_at AS db_dataset_created_at,
db_dataset.volume_dir AS db_dataset_volume_dir,
db_dataset.max_data_count AS db_dataset_max_data_count,
db_dataset.description AS db_dataset_description
FROM
db_dataset
LEFT OUTER JOIN db_manifest ON db_manifest.dataset_id = db_dataset.id AND
db_manifest.dataset_version = 'annotation_v0'
LEFT OUTER JOIN db_ai_data ON db_manifest.id = db_ai_data.manifest_id AND
db_ai_data.deleted = '0'
WHERE
db_dataset.deleted = 0
GROUP BY
db_dataset.id
Объяснение столбцов обратной связи плана выполнения:
Подробное объяснение Select_type:
Подробное объяснение типа:
查询使用了何种类型，它在 SQL优化中是一个非常重要的指标，以下性能从好到坏依次是：
system > const > eq_ref > ref > ref_or_null > index_merge > unique_subquery >
index_subquery > range > index > ALLsystem : когда в таблице есть только одна строка записей (системная таблица), объем данных очень мал, и дисковый ввод-вывод часто не требуется, а скорость очень высока.
const : указывает, что запрос соответствует первичному ключу первичного ключа или уникальному уникальному индексу, или связанная часть является постоянным (const) значением. Этот тип сканирования чрезвычайно эффективен, возвращает небольшое количество данных и выполняется очень быстро.
eq_ref : при запросе нажмите первичный ключ или индекс уникального ключа, а тип — eq_ref.
ref : В отличие от eq_ref, ref означает использование неуникального индекса, и будет найдено много строк, соответствующих условиям.
ref_or_null: этот тип объединения похож на ref, за исключением того, что MySQL будет дополнительно искать строки, содержащие значения NULL.
index_merge : используется метод оптимизации слияния индексов, а в запросе используется более двух индексов.
EXPLAIN SELECT * FROM user_robot_relate WHERE id > 1 AND user_id = 2;unique_subquery : замените следующий подзапрос IN, подзапрос возвращает уникальные коллекции.
value IN (SELECT primary_key FROM single_table WHERE some_expr)index_subquery: в отличие от unique_subquery используется для неуникальных индексов и может возвращать повторяющиеся значения.
value IN (SELECT key_column FROM single_table WHERE some_expr)range : выбор строк с использованием индекса, получение только строк в заданном диапазоне. Проще говоря, это получение данных в заданном диапазоне для индексированного поля. В операторе where используйте между... и, <, >, <=, in и другие типы условных запросов, все они являются диапазоном. Из результатов видно, что только для полей с установленными индексами тип поиска по диапазону — диапазон.
EXPLAIN SELECT * FROM user_robot_relate WHERE id BETWEEN 2 AND 3;index: Index и ALL фактически считывают всю таблицу, разница в том, что index проходит через дерево индексов для чтения, а ALL читает с жесткого диска.
ALL : будет пройдена вся таблица, чтобы найти совпадающие строки с наихудшей производительностью.
Дополнительно: информация, которая не подходит для отображения в других столбцах, и многие дополнительные сведения в объяснении будут отображаться в поле «Дополнительно».
Использование индекса: мы используем покрывающий индекс в соответствующей операции выбора.Вообще говоря, столбец запроса покрывается индексом, и скорость запроса будет очень высокой при использовании покрывающего индекса, что является идеальным состоянием для оптимизации SQL.
Использование «где»: во время запроса не найден доступный индекс, а затем необходимые данные получаются путем фильтрации условия «где», но следует отметить, что не все запросы с оператором «где» будут отображать «где».
Использование временных: указывает, что результаты запроса должны храниться во временной таблице, которая обычно используется при сортировке или группировке запросов.
Использование файловой сортировки: указывает на то, что операцию сортировки нельзя выполнить с использованием индекса, то есть поле ORDER BY не имеет индекса, и обычно такой SQL необходимо оптимизировать.
Использование буфера соединения: когда мы присоединяемся к запросу таблицы, если условие соединения таблицы не использует индекс, требуется буфер соединения для хранения промежуточных результатов.
2.3 Указатель
Отсортированная структура данных, которая помогает MySQL эффективно получать данные при индексировании.
Структура данных индекса:
бинарное дерево
красное черное дерево
Хеш-таблица
B-дерево
Как правило, причина отказа от использования бинарного дерева: упорядоченные данные вырождаются в связанный список, а глубина неуправляема, как показано на рисунке ниже.
Обычно причина, по которой нельзя использовать красно-черные деревья: Хотя глубина сжата, глубина все равно неуправляема, а сложность поиска массивных данных крайне высока.
Хэш-таблица: поддерживает только запрос IN, а не запрос RANGE. Используйте хэш-алгоритм для хеширования содержимого: хэш(aaaa) = 2 хеш(bbbb) = 2 хэш(cccc) = 4
Дерево B+: основная структура индекса
Процесс поиска:
1. Прочитайте все элементы корневого узла, поскольку они упорядочены, вы можете использовать двоичный поиск, чтобы эффективно найти указанный интервал.
2. Найдите вторичный узел по адресу файла указанного интервала и прочитайте все элементы.
3. Найдите указанную позицию элемента в листовом узле.
2.4 Принцип ускорения индексных запросов
Возьмем в качестве примера индекс дерева B+,
Если вы хотите найти элемент данных 29
1. Сначала введите блок 1, данные блока 1 загружаются в память, и происходит ввод-вывод.
2. Выполните двоичный поиск в памяти и обнаружите, что 29 предшествует 17 и 35, поэтому заблокируйте указатель P2, загрузите данные блока 3 в память, и произойдет еще один ввод-вывод.
3. Таким же образом переместите указатель P2 в блоке 3, чтобы заблокировать блок данных 8, загрузить блок данных 8 в память, и произойдет последний ввод-вывод.
4. Обходя данные блока 8, можно найти данные блока 29.
Если индекса нет, в худшем случае блоки данных всей таблицы должны быть загружены в память, а затем пройдены результаты, что приведет к большому количеству накладных расходов на ввод-вывод и просмотру всех данных таблицы.
2.5 Индекс фокусировки
Сфокусированные индексы особенно подходят для столбцов, требующих поиска в диапазоне RANGE, поскольку их конечные узлы хранят упорядоченные строки данных. В процессе запроса листовые узлы на обоих концах могут быть расположены в соответствии с условием WHERE, а затем может быть извлечена вся структура связанного списка между ними.
2.6 Принцип оптимизации левого префикса
В инженерных приложениях часто есть некоторые основные таблицы, которые необходимо запрашивать в нескольких формах.Если индекс создается для каждого метода запроса, это повлияет на производительность вставки и обновления таблицы.
Учитывая, что каждый подстолбец объединенного индекса сортируется при его создании, например, есть объединенная миниатюра (a, b, c) в таблице данных A, тогда запросите, где a = xxx, где a = xxx и b = xxx Это будет воплощение, поэтому вы можете использовать эту функцию, чтобы установить небольшое количество совместных индексов в соответствии с потребностями бизнеса для покрытия различных требований запросов.
Предполагая, что есть таблица A, есть следующие три высокочастотных запроса
select xx from A where a = xxx；
select xx from A where b = xxx；
select xx from A where a = xxx and b = xxx；Проще всего индексировать ab(a,b) отдельно, но это слишком многословно. В соответствии с принципом левого префикса наиболее разумным методом построения индекса должны быть b и (a, b).
2.7 Автоинкрементный индекс первичного ключа
1. Все данные в InnoDB хранятся на основе B + Tree.Если нет первичного ключа, mysql выберет столбец, который может быть уникальным среди всех столбцов в качестве идентификатора индекса.Если он не может быть найден, будет добавлен столбец rowid по умолчанию.
2. Будет сцена, где в процессе поиска по индексу сравнивается большое количество данных, если используется uuid, то сравниваться будет побитно, эффективность будет очень низкой, а пространство будет очень большим. много места на ssd будет занято, и стоимость хранения увеличится.
3. B+tree — это упорядоченное дерево. Данные индекса с автоматическим приращением можно постоянно вставлять в обратном порядке с высокой производительностью. в дополнительных потерях производительности.
3. Обычный порядок оптимизации базы данных
1. Проверить SQL, проверить план выполнения, попадает ли он в индекс? Много ли ассоциаций больших таблиц? Каждое поле запроса является обязательным? ...
2. Добавить индекс
3. Перегородка
4. Подтаблица
5. Измените структуру таблицы, уменьшите ассоциацию типов запросов и увеличьте избыточные поля.
6. Добавьте сервер, гибкий хост плюс U плюс память для замены SSD...
Нажмите, чтобы подписаться и узнать о свежих технологиях Huawei Cloud впервые~