Как определить, сколько времени будет выполняться запрос к БД?

Question

[afiskon]

Любимый вопрос начальства — «а сколько это будет считаться?». База большая, запросы сложные и все время разные (в смысле вообще разные, а не с разными аргументами). Как можно определить будущее время выполнения запросов в этом случае?

Comments

[s0rr0w]

Неплохо было бы указать название СУБД

[afiskon]

MySQL, иногда PostgreSQL

[afiskon]

Нужно ответить до запуска процесса, потому что времени он занимает долго, а запросы все время разные.

Answer 1

[papersaltserver]

Выполнить запрос на ограниченном числе записей, а потом экстраполировать на имеющееся число записей?

Comments

[afiskon]

Мысль хорошая. Но странно, что у СУБД нет встроенных средств для прогнозирования времени выполнения запроса.

[Александр]

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

Answer 2

[s0rr0w]

Я бы посоветовал разобраться, почему начальство до сих пор задает эти вопросы.
У меня есть несколько версий.

Начальство понятия не имеет, как идет процесс разработки, но им хочется показывать свою важность. Так как это риторический вопрос, на который вы всегда затрудняетесь ответить, этим они и самоутверждаются, стараясь понизить вашу оценку как работника. Выделим три основные проблемы
1. Начальство не владеет достаточным количеством информации для принятия решения.
Нужно рассказывать более подробно, почему вы не можете ответить на поставленный вопрос. Так как статистика о времени выполнения запросов не собирается, нужно предложить потратить немного времени на реогранизацию кода и начать собирать данные. Через время вы сможете ответить почти на любые из поставленных вопросов. Этот простой ход покажет вашу способность решать якобы неразрешимые проблемы и удовлетворит информационный голод начальства.
2. Начальство пытается самоутвердиться за ваш счет. Не обращайте на это внимание. Будьте выше этого.
3. Начальство пытается вас унизить и это реальный повод для беспокойства. Сделайте ход конем как описано в пункте 1, это уберет один из основных козырей давления — вашу несостоятельность ответить на вопрос. Если ваше предложение не будет принято, то это даст вам хороший ответ на вопрос: «Вы же не захотели собирать статистику, теперь какие ко мне вопросы?»

Еще одна из версий: начальство пытается понять, что не так в разработке, что нужно исправить, чтобы стало лучше. Или же пытается понять, как монетизировать конкурентные преимущества.

Истинные намерения легко определить спросив, почему вам задают такой вопрос. Не стесняйтесь, наступайте.

Answer 3

[Вячеслав Беликов]

В общем случае никак.

Answer 4

[Zamorozka]

Я бы просто провел практические тесты, если после них оказалось время не допустимо большим, то можно разбить запрос на под запросы, после этого выполнять каждый под запрос отдельно и смотреть время, тем самым найти слабое место.

Answer 5

[try4tune]

В MySQL такого нет. Проще оценить самому исходя из опыта и объема данных. Можно посмотреть вывод EXPLAIN на счет оптимизации.

Answer 6

[Алексей]

Ага, посчитайте время. А толку?
А когда таких запросов одновременно будет выполняться 10-20, а 100?
Я тоже как-то считал, 2-3 запроса — все летает, выпустили в продакшн — там 30-50 параллельно — все стало колом. Пока оперативы не добавили в сервер и БД не потюнили…

Answer 7

[Михаил]

Запомнить время до, после и показать разницу? или необходимо подсчитать не запуская процесс?

Comments

[afiskon]

Нужно ответить до запуска процесса, потому что времени он занимает долго, а запросы все время разные.

Answer 8

[Smileek]

declare @startTime datetime;
set @startTime = getutcdate();
-- Ваши запросы.
select datediff(ms, @startTime, getutcdate()); --ответ в миллисекундах

Или проблема в чем-то другом? Запросы еще не написаны?

Comments

[afiskon]

Запрос может считаться пару минут, а может и несколько часов. Нужно заранее ответить, будет готово к обеду или нет.

[afiskon]

Запросы все время разные.

[Дмитрий Дашкевич]

В большинстве случаев подойдет способ, который Вам предложили выше, т е выполнить тестовый запрос на небольшом кол-ве записей и рассчитать для всех.

[Smileek]

Ясно. Мудрые товарищи говорят, что нет в мускуле подобных средств прогнозирования, и есть только возможность примерной оценки на основе меньших выборок /*плюсанул ответ papersaltserver*/.

К вопросу, почему в СУБД нет встроенных средств прогнозирования: видимо, это очень дорого с точки зрения разработки/очень долго с точки зрения выполнении прогноза/дает очень грубый подсчет/всё вышеперечисленное.

Поверхностное гугление показало, что есть такая штука для Оракла — Discoverer — но и он делает очень грубый и очень приблизительный расчет исходя из предыдущих запросов.

[Артём Каретников]

Их нет потому, что прогнозировать это невозможно. Только предполагать. Вот предполагаете вы, что выполните работу для начальства за один час. А тут приходит другое, куда более высокое начальство и говорит: «бросай все, пошли со мной».

теперь давайте на базу данных это спроецируем:

insert into tbl_supertest(id, value)
select v.id_value, v.value from
tbl_value v
join tbl_valuedetail vd on v.id_value = vd.id_value

сколько времени будет выполнятся подобный запрос на 10 строчках? Политическая проститутка Троцкий скажет: «да за ноль секунд!» — и будет, как всегда, в корне не прав. Блокировочки! Другой процесс взял, и увел таблицу tbl_supertest с собой в режиме — запись запрещена. И? Пока он её не отдаст, никакой работы не будет. Конечно, мы с вами можем посчитать пока скорость выполнения селекта — но это здесь, в самом простом варианте.

А если мы пишем процедуру, и без данных в таблице tbl_supertest — дальше ничего работать не будет вообще? И это еще самый простой вариант.

Теперь пока вы там сидите и пытаетесь выполнить запрос с селектом — приходит еще сто тысяч пользователей и начинают писать в таблицу tbl_value — после чего записей в ней становится не 10, а сто миллионов. А индекс мы забыли с вами создать на tbl_valuedetail.id_value. Отразится это на времени исполнения? А через минуту нас осенило с вами, и мы индекс таки создали. Отразится это на времени исполнения?

И это я еще не учел наличие свободной памяти, скорость вашего жесткого диска, пренебрег фоновыми процессами и еще десятком важных деталей. Понимаете, почему это можно говорить лишь очень грубо?

Не в смысле: «Начальник, отвали с кретинским вопросом!», а в смысле «В мультиюзерной и мультизадачной среде ответить на вопрос ТОЧНО — невозможно. Даете монопольный доступ — будет примерно столько-то».

Answer 9

[Александр]

А в MySQL нельзя увидеть план запроса? По плану можно примерно понять какой характер зависимости времени выполнения от кол-ва записей

Answer 10

[shtopor]

Пришлите пожалуйста кто-нибудь инвайт, уж больно сильно хочется посмотреть на сию чуду-юду.
Благодарен за ранее.