Форум пользователей MySQL

FiMko · 24.03.2012 18:47:08

Всем привет!

Попытался искать ответ в вебе, но не нашел: при выполнении хранимой процедуры в консольном клиенте MySQL последний выводит в результате две статистики:

637 rows in set (0.85 sec)
Query OK, 0 rows affected (8.39 sec)

В чем разница между этими двумя временными показателями? Первый - реальное время работы процедуры, второе - время вывода результатов процедуры клиентом? Где про это почитать?

У меня, как можно заметить, второй показатель в 10 раз больше первого, пытаюсь понять, где что просело...

Отредактированно FiMko (24.03.2012 18:49:55)

rgbeast · 24.03.2012 18:53:34

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

FiMko · 24.03.2012 19:18:35

rgbeast написал:
Строчки относятся к двум запросам, выполняемым внутри процедуры.

Хм... похоже, что Query OK, X rows affected (X sec) все же относится к самой процедуре:

DROP PROCEDURE IF EXISTS myproc;

DELIMITER //

CREATE PROCEDURE myproc(

)

proc_start: BEGIN

    SELECT 1;

END //

DELIMITER ;

CALL myproc();

+---+

| 1 |

+---+

| 1 |

+---+

1 row in set (0.00 sec)

Query OK, 0 rows affected (0.00 sec)

DROP PROCEDURE IF EXISTS myproc;

DELIMITER //

CREATE PROCEDURE myproc(

)

proc_start: BEGIN

    SELECT 1;

    SELECT 2;

END //

DELIMITER ;

CALL myproc();

+---+

| 1 |

+---+

| 1 |

+---+

1 row in set (0.00 sec)

+---+

| 2 |

+---+

| 2 |

+---+

1 row in set (0.00 sec)

Query OK, 0 rows affected (0.01 sec)

То есть для каждого запроса в хранимой процедуре выводится row in set и время, а в конце, по всей видимости, время работы всей процедуры.

Почему, собственно, появился интерес: есть хранимая процедура, в ней запрос, я несколько раз попробовал выполнить этот запрос не в теле хранимой процедуры, время выполнения: ~0,15 секунд, но если я выполняю хранимую процедуру, содержащую ровным счетом тоже самое, то получаю:
194 rows in set (0.16 sec)
Query OK, 0 rows affected (2.37 sec)

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

Отредактированно FiMko (24.03.2012 19:52:37)

rgbeast · 24.03.2012 19:50:41

А что еще есть в процедуре, кроме запроса? Попробуйте профилирование: http://webew.ru/articles/2732.webew

FiMko · 24.03.2012 19:53:22

rgbeast написал:
А что еще есть в процедуре, кроме запроса? Попробуйте профилирование: http://webew.ru/articles/2732.webew

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

А как можно использовать профилирование применительно к процедурам? Выводит для всей процедуры за раз

| Query_ID | Duration   | Query

|        1 | 0.36730500 | SELECT... (тот самый SELECT ) |

Отредактированно FiMko (24.03.2012 21:12:44)

rgbeast · 24.03.2012 20:30:56

Да, процедуры профилировать не очень полезно - видно только время выполнения отдельных запросов в процедуре.

Может быть тратится время на передачу данных. Куда девается результат SELECT?

FiMko · 24.03.2012 21:12:20

rgbeast написал:
Да, процедуры профилировать не очень полезно - видно только время выполнения отдельных запросов в процедуре.

Может быть тратится время на передачу данных. Куда девается результат SELECT?

Да, тоже первое, что пришло на ум - передача данных, но подозрительно это очень, в 10 раз падает. Результат SELECT просто выводит из хранимой процедуры полученное множество. В сети то там, то здесь всплывают подобные нарекания - запрос работает быстро сам по себе и поразительно медленно в процедуре. В MSSQL человек решил установив ANSI_NULLS в ON, подозреваю, что в MySQL тоже к-н проблемы с конфигурацией или что-то вроде, не с передачей данных.

Отредактированно FiMko (24.03.2012 21:13:26)

rgbeast · 24.03.2012 21:20:00

В MySQL практически нет параметров, конфигурирующих поведение процедур.

FiMko · 24.03.2012 21:33:05

Собственно, о чем я говорю - комплексный запрос, проблема воспроизводится на тривиальнейшем примере:

mysql> show create table table1;

+--------+----------------------------

| Table  | Create Table

+--------+----------------------------

| table1 | CREATE TABLE `table1` (

  `id` int(11) NOT NULL,

  PRIMARY KEY (`id`)

) ENGINE=InnoDB DEFAULT CHARSET=utf8 |

+--------+----------------------------

mysql> select count(*) from table1;

+----------+

| count(*) |

+----------+

|    80500 |

+----------+

DROP PROCEDURE IF EXISTS myproc;

DELIMITER //

CREATE PROCEDURE myproc(

)

proc_start: BEGIN

    select id from table1 limit 10000;

END //

DELIMITER ;

call myproc();

10000 rows in set (0.02 sec)

Query OK, 0 rows affected (3.32 sec)

И похоже, да, rgbeast, вы правы по поводу передачи данных. Я когда в самом начале писал "время вывода результатов процедуры клиентом", собственно и имел в виду время, необходимое для передачи данных. Просто сейчас, когда вызвал myproc, на вскидку примерно 3,5 секунды и выводились результаты. Невероятно все равно, передача данных для MySQL по tcp в пределах одной и той же машины съедает секунды, в 10 раз больше времени, чем выполнение самого запроса.

В принципе, если в качестве клиента выступает PHP, чисто визуально я не вижу задержки в несколько секунд до начала отображения страницы, данные мгновенно начинают выводиться в браузер, но полная загрузка странички занимает как раз около двух-трех секунд. То есть данные готовы моментально, необходимо время на их передачу.

Отредактированно FiMko (24.03.2012 21:46:10)

rgbeast · 24.03.2012 21:56:51

Значит у вас нет проблемы - просто медленно работает терминал и консольный клиент.

FiMko · 24.03.2012 22:01:31

rgbeast написал:
Значит у вас нет проблемы - просто медленно работает терминал и консольный клиент.

Да, похоже... перебдел я. rgbeast, большое спасибо!

Форум пользователей MySQL

#1 24.03.2012 18:47:08

Rows in set и Rows affected

#2 24.03.2012 18:53:34

Re: Rows in set и Rows affected

#3 24.03.2012 19:18:35

Re: Rows in set и Rows affected

rgbeast написал:

#4 24.03.2012 19:50:41

Re: Rows in set и Rows affected

#5 24.03.2012 19:53:22

Re: Rows in set и Rows affected

rgbeast написал:

#6 24.03.2012 20:30:56

Re: Rows in set и Rows affected

#7 24.03.2012 21:12:20

Re: Rows in set и Rows affected

rgbeast написал:

#8 24.03.2012 21:20:00

Re: Rows in set и Rows affected

#9 24.03.2012 21:33:05

Re: Rows in set и Rows affected

#10 24.03.2012 21:56:51

Re: Rows in set и Rows affected

#11 24.03.2012 22:01:31

Re: Rows in set и Rows affected

rgbeast написал:

Board footer