offiziellen Jul 5 at 00:00

Оптимизация индексов базы данных: проблемы, решения, практические рекомендации

Medium

11 min

System Analysis and Design*Database Administration*High performance*Programming*Server optimization*

+28

Comments 5

VladimirFarshatov Jul 5 at 06:48

Хорошая статья, пасибки. Сжато и по делу. Позанудствую слегка только (ибо добавить особо и нечего):

Покрывающие индексы (Covering Indexes): Ультимативное оружие. Индекс содержит все поля из SELECT и WHERE. Базе вообще не нужно обращаться к таблице.

Напомню, что классический BTREE индекс это "разреженное дерево" (с пустыми местами), которое впервые было реализовано в mumps (1979?) и с тех пор используется как основа индексирования в БД. Чем была интересна эта самая БД mumps? А вот этим: покрыванием значений. Собственно это оно и есть. Основных таблиц с данными там не требовалось.

Отсюда, суть утверждения - это "работайте в mumps" это шустро и ультимативно.. без реляционных таблиц вовсе. Любопытно, не правда ли? Осталось сделать человечий интерфейс (а не то, что было) и ву-а-ля: "ультимативное оружие"..

О как, однако. )

Hamletghost Jul 5 at 17:19

Приведенный код это пример как вообще нельзя конструировать динамический запрос. Пользовательский ввод не должен попадать в текст запроса никогда. Если в фильтр города ввести что-то типа ‘; drop table users; -- что будет? Даже если вы будете как-то эскейпить ввод, все равно где-нибудь пропустите или налажаете.

Единственный корректный способ подстановки пользовательских значений в запрос - это использовать параметры:

… where city = ? … а значения передавать как параметры запроса.

HADGEHOGs Jul 6 at 15:19

Ввели BIGINT с AUTO_INCREMENT в качестве кластеризованного первичного ключа. Новые записи теперь всегда добавлялись в конец, что почти полностью устранило проблему.

И теперь мы курим бибу при параллельной вставки из за блокировки последней страницы...

VladimirFarshatov Jul 6 at 17:34

и осваиваем батч инсерт.. :)

Akina Jul 6 at 17:39

Неявное преобразование типов. WHERE user_id = '12345', когда user_id — число. Индекс отдыхает.

Ну это вообще-то зависит от СУБД.

Подход №1. Первый операнд выражения во WHERE задаёт контекст, и, коли поле числовое, то и контекст сравнения - числовой. Проблем с индексом нет.

Подход №2. Первый операнд выражения во WHERE числовой, второй строковый. Для определения контекста используется более общий тип, то есть контекст сравнения - строковый. Описанная проблема присутствует.