Dmitri Kuzmenko wrote:
Спасибо, но на мой взгляд все это слишком ужасно.
>...
мне почему-то хватает планов, информации о
количестве записей в таблицах и имеющихся индексах.
Вот потому-то я и говорю о сложных системах.
Если разработчиков несколько, код сложен, а разбираться детально нет
времени. Метод ужасен, но нет хоть сколько-нибудь адекватного
аналогичного метода для FB. По крайней мере, такой подход позволяет
выявить место возникновения безумства чтений и т.п.
Этот вопрос могла бы решить трассировка всех выражений в процедурах и
триггерах, включая execute statement. Могу сказать что в MSSQL именно
так я ловлю "сломавшиеся" запросы, т.к. и FB и MSSQL не застрахованы от
поломки после создания лишнего индекс (речь о запросах на выборку)
>Если интересует, почему у меня такое мнение -
>при оптимизации запросов я никогда не смотрю на
> s."Non-indexed Reads", s."Indexed Reads"
Ну кому как. Мне вот очень не хватает в упомянутом выше продукте этой
статистики. Порой именно количество чтений, а не километровая портянка с
планом, и знание реального количества записей в таблицах и результате
дают необходимую информацию для оптимизации.
