Как создать индекс (index) в базе данных SQL?

А, индексы в SQL, ну классика же! Это как если бы у тебя в гараже бардак полный, а ты на каждый ящик с инструментами наклеиваешь ярлык. Ищешь молоток — не надо весь хуй переворачивать, сразу идёшь к ящику с надписью «молотки, гвозди». Быстро, удобно, но наклеивать эти ярлыки — тоже время потратить.

Вот смотри, как это выглядит в коде, тут всё просто:

Базовый загон:

CREATE INDEX index_name ON table_name (column1, column2, ...);

Конкретные примеры, чтобы въехать:

1. Простейший индекс на одну колонку. Допустим, ищешь клиентов по мылу постоянно. Без индекса — это пиздец, таблицу всю просунет, как шмонают квартиру. С индексом — сразу в нужную папку заглянет.

CREATE INDEX idx_customers_email ON Customers (Email);

2. Уникальный индекс. Это когда ты говоришь: «Слышь, значение в этой колонке должно быть одно на весь район, повторяться — низя!». Если попробуешь впихнуть дубликат — получишь по рукам ошибкой.

CREATE UNIQUE INDEX idx_users_username ON Users (Username);

3. Составной индекс (на несколько полей). Представь, что ты ищешь сотрудников по отделу, а потом внутри отдела по зарплате. Составной индекс — это как сортировка в архиве: сначала папки по отделам, а внутри них — по алфавиту. Работает офигенно, если запрос использует оба поля или хотя бы первый из списка.

CREATE INDEX idx_employees_dept_salary ON Employees (DepartmentID, Salary);

4. Индекс с сортировкой по убыванию. Если тебе постоянно нужно «показать топ-10 самых дорогих», то индекс, заранее отсортированный по убыванию, может выдать результат моментально.

CREATE INDEX idx_employees_salary_desc ON Employees (Salary DESC);

Так когда же это добро создавать? Да когда чувствуешь, что запрос тормозит как телега в болоте:

• Колонка постоянно в WHERE мелькает.
• По ней джойны (JOIN) гоняют.
• Сортировки (ORDER BY) или группировки (GROUP BY) через неё идут.

Но предупреждаю сразу, не обольщайся!

• Не лепи индексы на всё, что движется. Каждый индекс — это отдельная хуйня, которую СУБД должна поддерживать в актуальном состоянии. Вставил новую запись — надо во все индексы её добавить. Удалил — из всех индексов выкинуть. Получается, что на каждую запись тратится больше времени. Добавил кучу индексов на таблицу, в которую часто пишут — и привет, она теперь обновляется со скоростью улитки.
• Используй EXPLAIN. Прежде чем орать «почему так медленно?!», запусти EXPLAIN перед своим запросом. Он тебе покажет, какие индексы используются, а какие — хуй с горы. В PostgreSQL, кстати, есть EXPLAIN ANALYZE, который не только план покажет, но и выполнит запрос, замерив время.
• Есть и хитрые штуки. В продвинутых СУБД можно сделать индекс не на весь столбец, а на результат выражения, или индекс только для части строк. Например, проиндексируй только активные заказы, а по archived — нихуя не надо.

  -- Допустим, в PostgreSQL
  CREATE INDEX idx_orders_active ON Orders (OrderDate) WHERE Status = 'Active';

• Кластеризованные и некластеризованные. Это важно, например, в SQL Server. Кластеризованный индекс — это как содержимое твоей тумбочки разложено строго в алфавитном порядке. Сами данные на диске так и лежат. Такой индекс может быть только один на таблицу. Некластеризованный — это просто отдельный список-оглавление, который ссылается на данные. Их можно сделать несколько.

Короче, индексы — это мощный инструмент, но не волшебная таблетка. Нужно балансировать между скоростью чтения и скоростью записи. Сначала анализируй запросы, потом уже лепи, где действительно надо.