Когда мы работаем с большими таблицами в SQL, использование индексов может значительно ускорить выполнение запросов, но их неправильное применение часто приводит к обратному эффекту.
Во-первых не всегда полезно устанавливать индекс, на каждый столбец этого делать уж точно не стоит. Каждый раз, когда мы используем
INSERT, UPDATE или DELETE, СУБД обновляет все индексы, что увеличивает затраты на производительность.Оптимальным решением будет индексировать только ключевые столбцы, часто используемые в фильтрах
WHERE или JOIN.-- Пример: индексирование часто используемого столбца
CREATE INDEX idx_user_age ON users(age);
-- Избыточный индекс на редко используемый столбец
CREATE INDEX idx_user_gender ON users(gender);
B-Tree и Hash-индексы. Стандартный B-Tree индекс эффективен для сортировки и диапазонных запросов (например,
BETWEEN). Но для точных соответствий = Hash-индексы могут быть предпочтительнее:-- B-Tree индекс для диапазонных значений
CREATE INDEX idx_order_date ON orders(order_date);
-- Hash-индекс для точного поиска
CREATE INDEX idx_product_id_hash ON products USING HASH (product_id);
И еще момент, если у нас выходит сложный запрос
WHERE, то важно учитывать порядок полей. Например, индекс на (col1, col2) будет эффективен, если col1 используется в фильтре или сортировке перед col2.-- Создаем композитный индекс
CREATE INDEX idx_comp_col1_col2 ON table_name(col1, col2);
-- Запрос, использующий оба поля индекса
SELECT * FROM table_name WHERE col1 = 'value' AND col2 = 'value';
-- Запрос, где используется только col2, неэффективен
SELECT * FROM table_name WHERE col2 = 'value';
В последнем запросе композитный индекс не будет использоваться оптимально, если col2 идет вторым в индексе.
Ставь 🔥 за полезный кусок знаний