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

💥💥💥 Ещё анонос и розыгрыш проходки! Через 2 недели (с 21 по 25 апреля) начнётся онлайн конференция Podlodka Php Crew которая будет проходить целых 5 дней. Тема сезона - High Performance. Т.е. про оптимизацию всего связанного и не связанного с php. Я там буду выступать и расскажу почему индексы не работают. Вообще тема индексов достаточно избитая, часто слышу "тормозят запросы в базу - создай индекс". Ну изи же. 🔹 А что если он не будет работать в условиях этого запроса? 🔹 Или вред от него будет выше, чем польза? 🔹 Или почему планировщик вообще игнорирует ваш, на первый взгляд, валидный индекс? Вообще с планировщиком всегда непросто, и не всегда понятно как он выбирает путь исполнения запроса и индекс. Но есть хитрости, как заставить, например, планировщик mysql использовать индекс. ✅ Директива USE INDEX Это, так скажем, "мягкая" рекомендация для планировщика выбрать указанный индекс. Но она может быть проигнорирована, если будет более оптимальный путь. SELECT * FROM users USE INDEX (idx_email) WHERE email = '[email protected]'; ✅ Директива FORCE INDEX "Жесткая" директива, требующая от потимизатора использовать указанный индекс, даже если он считает это не оптимальным. При этом оптимизатор игнорирует оценку стоимости альтренатив SELECT * FROM users FORCE INDEX (idx_email) WHERE email = '[email protected]'; Допустим есть запрос 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. Для этого нужно оставить любой комментарий к посту, победителя выберу случайным образом через неделю 🫡