Ответ
Классический пример — создание индексов на столбцы с низкой селективностью или дублирующих друг друга индексов, что замедляет операции записи (INSERT, UPDATE, DELETE) без выигрыша в чтении.
Пример 1: Индекс на столбец с малым количеством уникальных значений (низкая селективность).
-- Плохо: столбец 'status' может иметь всего 3-4 значения ('active', 'inactive', 'pending')
CREATE INDEX idx_status ON orders (status);
-- Запрос все равно просканирует большую часть таблицы
SELECT * FROM orders WHERE status = 'pending'; -- Индекс почти бесполезенПример 2: Избыточные индексы.
-- Допустим, есть составной индекс
CREATE INDEX idx_name_department ON employees (last_name, department_id);
-- Создание этого индекса часто избыточно, т.к. по первому столбцу составного индекса уже можно искать
CREATE INDEX idx_name ON employees (last_name); -- ЛИШНИЙ ИНДЕКС
-- Запрос `WHERE last_name = 'Smith'` уже может использовать `idx_name_department`.Пример 3: Индексы на часто изменяемые небольшие таблицы.
-- Таблица 'config' содержит 10 строк и обновляется часто
CREATE INDEX idx_config_key ON config (config_key);
-- Накладные расходы на поддержку индекса при каждой записи могут превысить редкую пользу от поиска.Практическое правило: Перед созданием индекса я анализирую запросы через EXPLAIN ANALYZE и учитываю селективность столбца, частоту операций записи и уже существующие индексы.
Ответ 18+ 🔞
А, ну это же классика, ёпта! Сидишь такой, думаешь: "Сейчас наклепаю индексов — всё полетит!" А в итоге получается пиздопроебибна, которая только жрёт ресурсы и тормозит запись. Слушай сюда, разжую.
Вот представь: у тебя есть столбец status в заказах. Там, блядь, три значения: 'active', 'inactive', 'pending'. И ты такой: "О, надо проиндексировать!" Создаёшь индекс, а он нихуя не работает. Почему? Да потому что селективность — ноль ебать! Запрос WHERE status = 'pending' всё равно выгребает треть таблицы, и оптимизатор часто машет рукой и идёт через полный сканирование. Ты просто зря потратил место и будешь этот индекс при каждом UPDATE перестраивать. Ядрёна вошь!
-- Плохо: столбец 'status' может иметь всего 3-4 значения ('active', 'inactive', 'pending')
CREATE INDEX idx_status ON orders (status);
-- Запрос все равно просканирует большую часть таблицы
SELECT * FROM orders WHERE status = 'pending'; -- Индекс почти бесполезенДальше — ещё хитрее. Вот есть у тебя составной индекс на (last_name, department_id). Всё чётко, красота. И тут тебе в голову стучит: "А дай-ка я ещё и на last_name отдельный индекс создам, для скорости!" Чувак, ты сам от себя охуеешь! Это же лишний индекс, ёбаный насос! Запрос по last_name и так может использовать тот, составной, потому что он начинается с этого столбца. Ты просто создаёшь дубликат, который будет занимать место и требовать обслуживания. Зачем?
-- Допустим, есть составной индекс
CREATE INDEX idx_name_department ON employees (last_name, department_id);
-- Создание этого индекса часто избыточно, т.к. по первому столбцу составного индекса уже можно искать
CREATE INDEX idx_name ON employees (last_name); -- ЛИШНИЙ ИНДЕКС
-- Запрос `WHERE last_name = 'Smith'` уже может использовать `idx_name_department`.И мой любимый перл — индексировать маленькие, но часто пишущиеся таблицы. Ну вот смотри: табличка config на 10 строк, которая постоянно апдейтится. И ты лепишь на неё индекс. Да похуй, что там 10 строк! Каждый UPDATE теперь должен ещё и индексный файл править. Накладные расходы — овердохуища, а польза — хуй с горы. Оно тебе надо?
-- Таблица 'config' содержит 10 строк и обновляется часто
CREATE INDEX idx_config_key ON config (config_key);
-- Накладные расходы на поддержку индекса при каждой записи могут превысить редкую пользу от поиска.Так что правило простое, блядь: не лепи индексы как бог на душу положит. Включи голову, э бошка думай! Перед тем как ткнуть CREATE INDEX, гони EXPLAIN ANALYZE на свои основные запросы. Посмотри, что там с селективностью, сколько операций записи, нет ли уже похожих индексов. А то получится, что ты оптимизируешь хуйню, а по-настоящему тяжёлые запросы так и будут ползти, как черепахи.