Ответ
Создание эффективного индекса требует анализа запросов и данных. Основные критерии:
- Нагрузка запросов: Индексируйте столбцы, которые часто фигурируют в условиях
WHERE,JOIN,ORDER BY,GROUP BY. - Селективность: Приоритет — столбцы с высоким количеством уникальных значений (например,
id,email). Индекс по полю с двумя значениями (gender) почти бесполезен. - Тип индекса:
- B-tree — для диапазонов (
BETWEEN,>,<) и сортировки. - Hash — только для точного совпадения (
=). - Составной (композитный) — для условий по нескольким столбцам. Порядок столбцов критичен!
- B-tree — для диапазонов (
- Влияние на запись: Каждый индекс замедляет операции
INSERT,UPDATE,DELETEи увеличивает объем хранилища. Необходим баланс.
Пример составного индекса:
-- Индекс эффективен для запросов с условием по department_id ИЛИ по department_id + salary.
CREATE INDEX idx_emp_dept_salary ON employees (department_id, salary);Ограничения: Индексы обычно не используются, если:
- В условии применяется функция к столбцу (
WHERE UPPER(name) = '...'). - Используется
LIKEс начальным wildcard ('%text').
Ответ 18+ 🔞
А, ну вот, опять про эти ваши индексы, блядь. Сидишь, значит, думаешь, как бы базу не угробить, а она тебе — «ой, всё медленно, ёпта!». Так, слушай сюда, разжую как для себя любимого.
Первое и главное, сука: не лепи индексы на всё подряд, как дурак! Каждый новый индекс — это как лишний рюкзак на твою INSERT/UPDATE операцию. Замедляет, блядь, и место жрёт. Баланс нужен, понимаешь? Чувство меры, ебать!
Теперь по пунктам, чтобы не распизделся:
1. Куда целиться?
Смотри, какие запросы у тебя самые частые и самые дохлые. Глазами, блядь, смотри на WHERE, JOIN, ORDER BY, GROUP BY. Вот по этим полям и думай. Если поле в WHERE постоянно мелькает — кандидат.
2. Селективность — это святое!
Представь, у тебя поле пол — два значения: «М» и «Ж». Ну и нахуя на него индекс? Чтобы выбрать половину таблицы? Ты чё, мудак? Это как искать иголку в стоге сена, а потом взять весь стог. Бесполезно, блядь! Индекс нужен на что-то уникальное, или почти уникальное: id, email, номер_паспорта. Чем уникальнее — тем жирнее польза.
3. Типы индексов — не еби мозг.
- B-tree — дефолтная рабочая лошадка. Для всего: поиск по равенству, диапазоны (
WHERE date > '2023'), сортировка. Бери его, если не уверен. - Hash — только для точного совпадения, когда тебе нужно
=и ничего больше. Быстрее, но ограниченно. Как одноразовый стаканчик. - Составной индекс (композитный) — вот тут, блядь, нужно мозги включать. Порядок столбцов — ВСЁ! Он как пароль, ебать. Если индекс на
(department_id, salary), то он сработает для поиска поdepartment_idи для связкиdepartment_id + salary. А вот если ты полезешь искать только поsalary— нихуя! Индекс проигнорируют. Запоминай: первый столбец в индексе — главный, как ключ от квартиры.
Вот, смотри, пример, чтобы в голове отложилось:
-- Делаем индекс. department_id — главный ключик.
CREATE INDEX idx_emp_dept_salary ON employees (department_id, salary);Такой индекс, блядь, выручит, если ты ищешь всех из отдела 5 (WHERE department_id = 5) или всех из отдела 5 с зарплатой больше стакана (WHERE department_id = 5 AND salary > 100000). Умная штука.
4. Когда индекс — просто кусок бесполезного мяса? Бывает, сделаешь индекс, а запрос всё равно ползёт, как черепаха. Значит, накосячил. Индекс обычно не используют, если:
- Ты начинаешь ебаться со столбцом через функцию:
WHERE UPPER(name) = 'ВАСЯ'. База смотрит на индекс поname, а видитUPPER(name)— и пизда. Не совпало. Индекс — не для извращенцев. - Используешь
LIKEс процентом в начале:WHERE name LIKE '%Вася'. Это как искать человека, зная только последнюю букву его имени — нихуя не найдёшь. Индекс тут бессилен. А вот'Вася%'— уже ок, может прокатить.
Короче, суть в чём: думай, блядь, что ты чаще всего ищешь, делай индекс под это, не плоди хуйню и не трогай столбцы функциями на лету. Всё, можно идти пить чай.