Сравнение производительности MySQL между хранимой процедурой и подготовленными операторами

Вот подготовленный оператор MySQL

SELECT 
    ag.`attendance_type`,
    ag.`description`,
    COUNT(a.`attendance`) attendance_count 
FROM
    `ems_attendance` a 
    RIGHT JOIN `ems_att_group` ag 
        ON ag.`id` = a.`attendance` 
        AND a.`added_date` BETWEEN '2011-06-01' 
        AND '2011-06-17' 
        AND a.`users_id` = '9' 
GROUP BY a.`attendance` 
ORDER BY ag.`id`;

и эквивалентная процедура хранения

DELIMITER $$

DROP PROCEDURE IF EXISTS `users_attendance_report` $$

CREATE PROCEDURE `users_attendance_report` (
    IN users_id INT,
    IN start_date DATE,
    IN end_date DATE
) 
BEGIN
    SELECT 
        ag.`attendance_type`,
        ag.`description`,
        COUNT(a.`attendance`) attendance_count 
    FROM
        `ems_attendance` a 
        RIGHT JOIN `ems_att_group` ag 
            ON ag.`id` = a.`attendance` 
            AND a.`added_date` BETWEEN start_date 
            AND end_date 
            AND a.`users_id` = users_id 
    GROUP BY a.`attendance` 
    ORDER BY ag.`id` ;
END $$

DELIMITER;

После запуска запроса оба выводят одинаковые результаты.

Array
(
    [0] => stdClass Object
        (
            [attendance_type] => present
            [description] => Present
            [attendance_count] => 10
        )

    [1] => stdClass Object
        (
            [attendance_type] => absent
            [description] => Absent
            [attendance_count] => 2
        )

    [2] => stdClass Object
        (
            [attendance_type] => other
            [description] => Other
            [attendance_count] => 0
        )

    [3] => stdClass Object
        (
            [attendance_type] => dayoff
            [description] => Day Off
            [attendance_count] => 2
        )

)

Я внимательно смотрю на время выполнения, оба одинаковы. Когда и где один лучше и быстрее другого?


person Madan Sapkota    schedule 17.06.2011    source источник


Ответы (2)


«Быстрее» и «лучше» не обязательно совпадают. См. эту аналогию SO задайте вопрос и рассмотрите следующие атрибуты решения:

  • ремонтопригодный (читабельный, требования к навыкам - кто может работать над этим кодом)
  • проверяемый
  • съемный
  • гибкий
  • портативный

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

person Bohemian♦    schedule 17.06.2011
comment
Да, но также учитывайте целостность и безопасность. Хранимые процедуры выигрывают по этим показателям. Хранимая процедура может иметь права доступа, отличные от таблицы. Это означает, что вы можете, например, запретить доступ к таблице, кроме как с помощью четко определенного способа реализации хранимой процедуры. Кроме того, вы можете исключить большинство случаев случайных или неаккуратных неверных/несогласованных данных. Наконец, намного сложнее успешно использовать скрипт, который вызывает хранимую процедуру, а не отправлять необработанный SQL на сервер БД (не говорю, что это невозможно, но определенно намного сложнее). - person Damon; 17.06.2011
comment
Конечно, все, что вы говорите, верно, но PL/SQL слишком сложно поддерживать, отлаживать и т. д. Большинство баз данных откладывают контроль над доступом пользователей к ОС/приложению; редко они делают это сами (на уровне пользователя приложения). Кроме того, PL/SQL — более редкий навык, чем программирование приложений, и, откровенно говоря, менее дисциплинированный ИМХО. В среднесрочной/долгосрочной перспективе вы будете благодарны, что не пошли туда, особенно для любой бизнес-логики. - person Bohemian♦; 17.06.2011

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

person Abhay    schedule 17.06.2011