Есть некий API доступа к данным, позволяющий указывать критерии фильтрации (по любому из N полей, по нескольким полям через and/or), сортировку (по любому из N полей) и паджинацию. По запросам к этом API строятся ORM-запросы (Java, Criteria builder), которые потом идут в Mysql. Запросы, конечно, получаются очень разными, а уж планы выполнения — так ещё разнее. Хочется чтобы любой запрос отрабатывал за 1 секунду при 10 параллельных юзерах. О тормозах мы часто узнаём от внешних потребителей. Показывают что они как хотят отфильтровать, мы воспроизводим, смотрим план, придумываем как сделать быстрее. Например индекс добавляем. Хочется придумать как отлавливать наибольшее число тормозных запросов как можно раньше — до того, как внешние потребители с этим столкнутся.

У нас есть ежедневные перформанс тесты, которые проверяют какие-то сочетания каких-то параметров и от них есть выхлоп, но все возможные сочетания проверять конечно не получится — тупо очень много времени займёт, если каждую конфигурацию мучать хотя бы по 15 секунд.

Приходит в голову написать "юнит тесты", которые бы проверяли как выглядит план выполнения запроса для каждой возможной конфигурации параметров, и убеждались бы, что там точно нигде никогда нет full scan например. Будут такие тесты иметь смысл? Как бы вы подошли к проблеме?