TGViewer
Open Source: PHP Open Source: PHP @open_source_php · 422 subscribers
Post #32 728

Forwarded from Олег Мифле | System Design, AI, архитектура

💥💥💥 Ещё анонос и розыгрыш проходки!

Через 2 недели (с 21 по 25 апреля) начнётся онлайн конференция Podlodka Php Crew которая будет проходить целых 5 дней. Тема сезона - High Performance. Т.е. про оптимизацию всего связанного и не связанного с php. Я там буду выступать и расскажу почему индексы не работают. Вообще тема индексов достаточно избитая, часто слышу "тормозят запросы в базу - создай индекс". Ну изи же.
🔹 А что если он не будет работать в условиях этого запроса?
🔹 Или вред от него будет выше, чем польза?
🔹 Или почему планировщик вообще игнорирует ваш, на первый взгляд, валидный индекс?

Вообще с планировщиком всегда непросто, и не всегда понятно как он выбирает путь исполнения запроса и индекс. Но есть хитрости, как заставить, например, планировщик mysql использовать индекс.

✅ Директива USE INDEX
Это, так скажем, "мягкая" рекомендация для планировщика выбрать указанный индекс. Но она может быть проигнорирована, если будет более оптимальный путь.

SELECT * FROM users USE INDEX (idx_email) WHERE email = 'example@mail.com';


✅ Директива FORCE INDEX
"Жесткая" директива, требующая от потимизатора использовать указанный индекс, даже если он считает это не оптимальным. При этом оптимизатор игнорирует оценку стоимости альтренатив

SELECT * FROM users FORCE INDEX (idx_email) WHERE email = 'example@mail.com';


Допустим есть запрос

SELECT * FROM orders WHERE customer_id = 42 AND status = 'done';

записей с customer_id=42, допустим, 1000 с разными значениями в status, а со status = done и разными customer_id - 50000.

И есть 2 индекса - на customer_id, и на status. Тут планировщик выберет customer_id, это более селективно.
Но вот мы взяли и зафорсили индекс по status, нам показалось так лучше (и это может действительно лучше в каких-то сценариях) -

SELECT * FROM orders FORCE INDEX (idx_status) WHERE customer_id = 42 AND status = 'done';

в итоге получим, что сначала запрос отберёт 50000 записей со status = done, а потом из них возмёт 100 записей с customet_id 42. Вот такая оптимизация.

В PostgreSQL такогих деректив нет. Но есть другие "приёмы" как можно скорректировать работу планировщика.
Вообще, на мой взгляд, к такому нужно относится с большой осторожностью. Если без костылей не получается завести индекс, вероятно что-то мы делаем не так.

В своём докладе я расскажу и об этом, и о том почему индексы игнорируются или работают не эфективно. У меня есть проходка на мероприятие и ,если мой доклад интересен, то есть шанс послушать его в живую, а так же все остальные с Podlodka Php Crew. Для этого нужно оставить любой комментарий к посту, победителя выберу случайным образом через неделю 🫡
podlodka.io Онлайн-конференция Podlodka PHP Crew, сезон #8 Недельное мероприятие от команды Podlodka: ежедневные интерактивные сессии в Zoom по актуальным вопросам PHP-индустрии, нон-стоп общение с экспертами и звёздами индустрии, закрытое профессиональное сообщество в Telegram.
  • 👍 4
  • 🔥 1
  • 👨‍💻 1
More from @open_source_php
  1. Sep 17, 2026Простая задача, чтобы вкатиться в ряды контрибьюторов Testo https://github.com/php-testo/t…
  2. Nov 25, 2025True Async PHP Edmond Dantes призывает всех к обсуждению особенностей реализации нашумевше…
  3. Nov 11, 2025Сегодня состоялся релиз open-source админки MoonShine v4! Вкратце по нововведениям рассказ…
  4. Oct 21, 2025🤎 Драйвер для NATS от Thesis! Каждый, кто пишет на Golang, наверняка слышал про NATS. Это…
  5. Oct 13, 2025Есть задачка посложнее. Нужно добавить поддержку игнорирования мутаторов: - infection-igno…
  6. Oct 13, 2025📣 Infection – библиотека для мутационных тестов Infection довольно круто инструменты для…
Threads Profile ViewerView any public Threads profile without an account.Open ThreadLook →Writing with AI? Make it sound human.Metric37 rewrites AI drafts so they read naturally. Free AI detector, 1,500 words free.Try Metric37 →