Подходит ли платформа для начинающих без опыта работы?

Да, курсы разбиты по уровням: Junior, Middle, Senior. Начинающие могут стартовать с базовых тем Python, Docker и алгоритмов и постепенно двигаться к более сложным темам.

Как быстро можно подготовиться к собеседованию на позицию Junior разработчика?

При занятиях 1–2 часа в день — от 2 до 4 недель на основные темы. Платформа анализирует слабые места по результатам квизов и строит персональный план подготовки.

Какие технологии охватывает платформа?

Python, FastAPI, Django, Docker, алгоритмы и структуры данных, Agile/Scrum, SQL, CI/CD, системный дизайн, код-ревью и более 50 других тем для разработчиков.

Платформа бесплатная?

Большинство учебных материалов и квизов доступны бесплатно после регистрации. Регистрация занимает менее минуты.

Как платформа помогает найти работу программистом?

Платформа даёт фундаментальные знания, которые проверяют на технических собеседованиях: алгоритмы, архитектура, фреймворки. Мок-интервью имитирует реальное собеседование. Система прогресса показывает, какие темы нужно подтянуть перед собеседованием.

composite_index

Составные индексы

Многоколоночные индексы, порядок колонок, правило левой границы.

Составные индексы

Порядок колонок в составном индексе — это не деталь реализации, а фундаментальное решение, определяющее эффективность запросов.

1. Что такое составной индекс

Составной индекс (composite index) — это индекс по нескольким колонкам одновременно.

-- Индекс по двум колонкам
CREATE INDEX idx_users_name ON users(last_name, first_name);

-- Индекс по трём колонкам
CREATE INDEX idx_orders ON orders(user_id, status, created_at);

Когда использовать

Сценарий	Пример
Частые комбинации условий	`WHERE last_name = ? AND first_name = ?`
Сортировка по нескольким колонкам	`ORDER BY status, created_at`
Покрытие частых запросов	`WHERE user_id = ? AND status = ?`

Ограничения

Максимум 32 колонки в индексе
На практике эффективно 2-4 колонки
Каждая дополнительная колонка увеличивает размер индекса

2. Правило левой границы (Leftmost Prefix)

Самое важное правило составных индексов!

Составной индекс по колонкам (A, B, C) может использоваться для запросов по:

✅ A
✅ A, B
✅ A, B, C

Но НЕ для:

❌ B
❌ C
❌ B, C
❌ A, C (пропуск B)

2.1. Почему так работает

B-дерево сортирует данные лексикографически — сначала по первой колонке, затем внутри каждого значения первой колонки — по второй, и так далее.

Индекс (last_name, first_name):

ivanov    ivan      TID=1
ivanov    ivan      TID=2  ← Дубликаты last_name сортируются по first_name
ivanov    petr      TID=3
petrov    alex      TID=4
petrov    boris     TID=5
sidorov   alex      TID=6

Поиск по `last_name = 'ivanov'`:

✅ Находим начало диапазона ivanov
✅ Читаем все записи с last_name = 'ivanov'
✅ Быстро!

Поиск по `first_name = 'ivan'`:

❌ Записи с first_name = 'ivan' разбросаны по всему дереву
❌ Приходится сканировать весь индекс
❌ Медленнее Seq Scan!

3. Примеры использования правила левой границы

3.1. Индекс для имени и фамилии

CREATE INDEX idx_name ON users(last_name, first_name);

-- ✅ Использует индекс
SELECT * FROM users WHERE last_name = 'Ivanov';

-- ✅ Использует индекс
SELECT * FROM users WHERE last_name = 'Ivanov' AND first_name = 'Ivan';

-- ❌ НЕ использует индекс (или использует плохо)
SELECT * FROM users WHERE first_name = 'Ivan';

-- ✅ Использует только первую колонку
SELECT * FROM users 
WHERE last_name = 'Ivanov' AND first_name = 'Ivan' AND email = 'test@example.com';

3.2. Индекс для заказов

CREATE INDEX idx_orders ON orders(user_id, status, created_at);

-- ✅ Использует индекс
SELECT * FROM orders WHERE user_id = 123;

-- ✅ Использует индекс
SELECT * FROM orders WHERE user_id = 123 AND status = 'pending';

-- ✅ Использует индекс полностью
SELECT * FROM orders 
WHERE user_id = 123 AND status = 'pending' AND created_at > '2026-01-01';

-- ❌ НЕ использует индекс
SELECT * FROM orders WHERE status = 'pending';

-- ⚠️ Использует только первую колонку (user_id)
SELECT * FROM orders 
WHERE user_id = 123 AND created_at > '2026-01-01';
-- status пропущен, но created_at может использоваться для фильтрации

4. Выбор порядка колонок

Порядок колонок критически важен. Рассмотрим таблицу заказов:

CREATE TABLE orders (
    id BIGSERIAL,
    user_id BIGINT,
    status VARCHAR(20),
    amount DECIMAL,
    created_at TIMESTAMP
);

4.1. Анализ запросов

Запрос	Частота
`WHERE user_id = ?`	50%
`WHERE user_id = ? AND status = ?`	30%
`WHERE status = ?`	10%
`WHERE status = ? AND created_at > ?`	10%

4.2. Вариант 1: `(user_id, status)`

CREATE INDEX idx_orders_v1 ON orders(user_id, status);

Запрос	Работает?
`WHERE user_id = ?`	✅ Да
`WHERE user_id = ? AND status = ?`	✅ Да
`WHERE status = ?`	❌ Нет
`WHERE status = ? AND created_at > ?`	❌ Нет

Охват: 80% запросов

4.3. Вариант 2: `(status, user_id)`

CREATE INDEX idx_orders_v2 ON orders(status, user_id);

Запрос	Работает?
`WHERE user_id = ?`	❌ Нет
`WHERE user_id = ? AND status = ?`	⚠️ Частично (только status)
`WHERE status = ?`	✅ Да
`WHERE status = ? AND created_at > ?`	⚠️ Частично (только status)

Охват: 20% запросов эффективно

4.4. Вывод

Вариант 1 лучше, потому что:

Покрывает 80% запросов
user_id имеет высокую селективность (один пользователь = мало заказов)
status имеет низкую селективность (несколько статусов = много заказов)

4.5. Правило выбора порядка

Селективность — более селективная колонка должна быть первой
Частота использования — колонки из частых запросов должны быть левее
Постоянство — колонки, которые всегда есть в WHERE, должны быть левее

5. Составные индексы для сортировки

Составной индекс может устранить сортировку для ORDER BY.

5.1. Прямой порядок

CREATE INDEX idx_orders_sort ON orders(user_id, created_at DESC);

-- ✅ Использует индекс для сортировки
SELECT * FROM orders 
WHERE user_id = 123 
ORDER BY created_at DESC;

5.2. Обратный порядок

Индекс можно сканировать в обратном направлении:

-- ✅ Тоже использует индекс (сканирование справа налево)
SELECT * FROM orders 
WHERE user_id = 123 
ORDER BY created_at ASC;

5.3. Смешанный порядок

CREATE INDEX idx_mixed ON orders(status ASC, created_at DESC);

-- ✅ Использует индекс
SELECT * FROM orders 
ORDER BY status ASC, created_at DESC;

-- ❌ НЕ использует индекс для сортировки
SELECT * FROM orders 
ORDER BY status DESC, created_at DESC;
-- Направления не совпадают

5.4. WHERE + ORDER BY

CREATE INDEX idx_orders_optimal ON orders(user_id, status, created_at DESC);

-- ✅ Идеальное совпадение
SELECT * FROM orders 
WHERE user_id = 123 AND status = 'pending'
ORDER BY created_at DESC
LIMIT 10;

PostgreSQL:

Находит диапазон user_id = 123
Внутри него фильтрует по status = 'pending'
Читает в порядке created_at DESC (уже отсортировано!)
Останавливается после 10 строк

Сортировка не требуется!

6. Составные индексы для covering index

CREATE INDEX idx_covering ON orders(user_id, status) INCLUDE (amount, created_at);

-- ✅ Index Only Scan — все данные в индексе
SELECT user_id, status, amount, created_at 
FROM orders 
WHERE user_id = 123 AND status = 'pending';

Ключевые колонки (user_id, status) используются для поиска, INCLUDE-колонки хранятся в листовых узлах.

7. Частичные составные индексы

Комбинация составного индекса с частичным (WHERE-условием):

CREATE INDEX idx_active_users 
ON users(last_name, first_name) 
WHERE active = true;

-- ✅ Использует индекс
SELECT * FROM users 
WHERE active = true 
  AND last_name = 'Ivanov' 
  AND first_name = 'Ivan';

8. Диагностика составных индексов

8.1. Проверка использования

SELECT 
    indexrelname,
    idx_scan as scans,
    idx_tup_read as tuples_read
FROM pg_stat_user_indexes
WHERE indexrelname = 'idx_users_name';

8.2. Анализ плана выполнения

EXPLAIN (ANALYZE, BUFFERS)
SELECT * FROM orders 
WHERE user_id = 123 AND status = 'pending';

Ищите:

Index Scan — используется ли индекс
Index Cond — какие условия применены
Rows — сколько строк фактически прочитано

8.3. Обнаружение неиспользуемых индексов

SELECT 
    indexrelname,
    idx_scan,
    pg_size_pretty(pg_relation_size(indexrelid)) as size
FROM pg_stat_user_indexes
WHERE schemaname = 'public'
  AND idx_scan = 0
ORDER BY pg_relation_size(indexrelid) DESC;

9. Типичные ошибки

9.1. Неправильный порядок колонок

-- ❌ Плохо: status имеет низкую селективность
CREATE INDEX idx_bad ON orders(status, user_id);

-- ✅ Хорошо: user_id более селективен
CREATE INDEX idx_good ON orders(user_id, status);

9.2. Избыточные индексы

CREATE INDEX idx_v1 ON orders(user_id);
CREATE INDEX idx_v2 ON orders(user_id, status);  -- ❌ idx_v1 избыточен!

Индекс (user_id, status) может использоваться как (user_id). Удалите idx_v1.

9.3. Слишком много колонок

-- ❌ Плохо: 10 колонок — огромный индекс, медленная вставка
CREATE INDEX idx_huge ON orders(
    user_id, status, amount, created_at, 
    updated_at, region, category, priority, 
    assigned_to, completed_at
);

-- ✅ Хорошо: 2-4 ключевые колонки
CREATE INDEX idx_optimal ON orders(user_id, status, created_at);

9.4. Игнорирование правила левой границы

-- Запросы только по first_name
SELECT * FROM users WHERE first_name = 'Ivan';

-- ❌ Бесполезный индекс
CREATE INDEX idx_wrong ON users(last_name, first_name);

-- ✅ Правильный индекс
CREATE INDEX idx_right ON users(first_name, last_name);

10. Best practices

✅ Делайте

Анализируйте реальные запросы перед созданием индекса
Ставьте более селективные колонки первыми
Используйте 2-4 колонки максимум
Удаляйте избыточные индексы (если есть (A, B), то (A) не нужен)
Учитывайте сортировку в ORDER BY

❌ Не делайте

Не создавайте индексы без анализа запросов
Не ставьте низкоселективные колонки первыми (boolean, status)
Не создавайте индексы с 5+ колонками
Не игнорируйте правило левой границы
Не забывайте удалять неиспользуемые индексы

11. Практический пример

Задача: Оптимизация отчёта

-- Частый запрос в отчёте
SELECT user_id, status, COUNT(*), SUM(amount)
FROM orders
WHERE created_at BETWEEN '2026-01-01' AND '2026-01-31'
GROUP BY user_id, status;

Анализ

Фильтр: created_at BETWEEN ...
Группировка: user_id, status
Таблица: 10 млн записей

Решение

CREATE INDEX idx_orders_report ON orders(created_at, user_id, status);

Почему такой порядок:

created_at — используется в WHERE (фильтр по диапазону)
user_id, status — для GROUP BY (данные уже сгруппированы в индексе)

Результат

-- До: Seq Scan, 1500 ms
-- После: Index Only Scan, 50 ms

12. Что дальше?

Покрывающие индексы — INCLUDE для ещё большей эффективности
Частичные индексы — WHERE-условие для экономии места
Как оптимизатор выбирает индексы — внутренняя логика выбора плана

Ключевые выводы

Правило левой границы — индекс (A, B, C) работает для A, A+B, A+B+C
Порядок колонок критичен — ставьте селективные и частые колонки первыми
2-4 колонки максимум — больше неэффективно
Учитывайте сортировку — индекс может устранить ORDER BY
Удаляйте избыточные — если есть (A, B), то (A) не нужен

Проверьте свои знания

Вопросы ещё не добавлены

Вопросы для этой подтемы ещё не добавлены.

Сценарий

Пример

Частые комбинации условий

WHERE last_name = ? AND first_name = ?

Сортировка по нескольким колонкам

ORDER BY status, created_at

Покрытие частых запросов

WHERE user_id = ? AND status = ?

Индекс (last_name, first_name): ivanov ivan TID=1 ivanov ivan TID=2 ← Дубликаты last_name сортируются по first_name ivanov petr TID=3 petrov alex TID=4 petrov boris TID=5 sidorov alex TID=6

Запрос

Частота

WHERE user_id = ?

50%

WHERE user_id = ? AND status = ?

30%

WHERE status = ?

10%

WHERE status = ? AND created_at > ?

10%

Запрос

Работает?

WHERE user_id = ?

✅ Да

WHERE user_id = ? AND status = ?

✅ Да

WHERE status = ?

❌ Нет

WHERE status = ? AND created_at > ?

❌ Нет

Запрос

Работает?

WHERE user_id = ?

❌ Нет

WHERE user_id = ? AND status = ?

⚠️ Частично (только status)

WHERE status = ?

✅ Да

WHERE status = ? AND created_at > ?

⚠️ Частично (только status)

Составные индексы

Составные индексы

1. Что такое составной индекс

Когда использовать

Ограничения

2. Правило левой границы (Leftmost Prefix)

2.1. Почему так работает

Поиск по last_name = 'ivanov':

Поиск по first_name = 'ivan':

3. Примеры использования правила левой границы

3.1. Индекс для имени и фамилии

3.2. Индекс для заказов

4. Выбор порядка колонок

4.1. Анализ запросов

4.2. Вариант 1: (user_id, status)

4.3. Вариант 2: (status, user_id)

4.4. Вывод

4.5. Правило выбора порядка

5. Составные индексы для сортировки

5.1. Прямой порядок

5.2. Обратный порядок

5.3. Смешанный порядок

5.4. WHERE + ORDER BY

6. Составные индексы для covering index

7. Частичные составные индексы

8. Диагностика составных индексов

8.1. Проверка использования

8.2. Анализ плана выполнения

8.3. Обнаружение неиспользуемых индексов

9. Типичные ошибки

9.1. Неправильный порядок колонок

9.2. Избыточные индексы

9.3. Слишком много колонок

9.4. Игнорирование правила левой границы

10. Best practices

✅ Делайте

❌ Не делайте

11. Практический пример

Задача: Оптимизация отчёта

Анализ

Решение

Результат

12. Что дальше?

Ключевые выводы

Проверьте свои знания

Составные индексы

Составные индексы

1. Что такое составной индекс

Когда использовать

Ограничения

2. Правило левой границы (Leftmost Prefix)

2.1. Почему так работает

Поиск по last_name = 'ivanov':

Поиск по first_name = 'ivan':

3. Примеры использования правила левой границы

3.1. Индекс для имени и фамилии

3.2. Индекс для заказов

4. Выбор порядка колонок

4.1. Анализ запросов

4.2. Вариант 1: (user_id, status)

4.3. Вариант 2: (status, user_id)

4.4. Вывод

4.5. Правило выбора порядка

5. Составные индексы для сортировки

5.1. Прямой порядок

5.2. Обратный порядок

5.3. Смешанный порядок

5.4. WHERE + ORDER BY

6. Составные индексы для covering index

7. Частичные составные индексы

8. Диагностика составных индексов

8.1. Проверка использования

8.2. Анализ плана выполнения

8.3. Обнаружение неиспользуемых индексов

9. Типичные ошибки

9.1. Неправильный порядок колонок

9.2. Избыточные индексы

9.3. Слишком много колонок

9.4. Игнорирование правила левой границы

10. Best practices

Поиск по `last_name = 'ivanov'`:

Поиск по `first_name = 'ivan'`:

4.2. Вариант 1: `(user_id, status)`

4.3. Вариант 2: `(status, user_id)`

Поиск по `last_name = 'ivanov'`:

Поиск по `first_name = 'ivan'`:

4.2. Вариант 1: `(user_id, status)`

4.3. Вариант 2: `(status, user_id)`