MySQL Simple Select - Performances des procédures stockées

Question

Je suis en train de développer une procédure stockée sur MySQL et j'attendais un léger gain de vitesse. Mais quand je l'ai comparé à l'exécution de requêtes SQL via un script PHP, PHP était plus rapide. Avec une table de 1000 lignes environ 10 fois plus rapide et une table de 6000 lignes environ deux fois plus rapide.

La taille de la table améliore-t-elle ou non les performances des procédures? Ai-je fait une erreur dans mon code et puis-je l'optimiser?

Ma configuration est le moteur MyIsam sur MySQL 5.0.10. Ma procédure stockée est

CREATE PROCEDURE get_task (IN var INT) 
BEGIN 
    DECLARE id_task INT (11); 
    DECLARE job INT (11); 
    DECLARE state_name VARCHAR(20); 
    DECLARE task_name VARCHAR(20); 
    DECLARE worker_affected INT(11); 
    DECLARE user VARCHAR(10); 
    DECLARE progress INT(11); 
    DECLARE name VARCHAR(128); 
    DECLARE phone VARCHAR(128); 
    DECLARE mobile VARCHAR(128); 
    DECLARE site VARCHAR(32); 
    DECLARE worker_name VARCHAR(20); 
    DECLARE date_time_process_started DATETIME; 
    DECLARE frame INT(11); 

    DECLARE curseur1 CURSOR FOR 

    SELECT tq.`id_task`, tq.`job`, lts.`state_name`, ltt.`task_name`, tq.`worker_affected`, j.`user`, tq.`progress`, u.`name`, u.`phone`, u.`mobile`, u.`site`, w .`worker_name`, tq.`date_time_process_started`, tq.`frame` 
    FROM `task_queue` tq 
    LEFT JOIN `workers` w ON tq.`worker_affected` = w.`id_worker` 
      INNER JOIN `job` j ON tq.`job` = j.`job_id` 
      INNER JOIN `user` u ON j.`user` = u.`ipn` 
      INNER JOIN `list_task_type` ltt ON tq.`task_type` = ltt.`id_type_task` 
      INNER JOIN `list_task_state` lts ON tq.`task_state` = lts.`id_state` 
    WHERE tq.`id_task` = var 
    ORDER BY tq.`id_task`; 

    OPEN curseur1; 

    FETCH curseur1 INTO id_task, job, state_name, task_name, worker_affected, user, progress, name, phone, mobile, site, worker_name, date_time_process_started, frame; 
    SELECT id_task, job, state_name, task_name, worker_affected, user, progress, name, phone, mobile, site, worker_name, date_time_process_started, frame; 

    CLOSE curseur1; 

END | 

Answer 1

Votre procédure stockée, comme il est écrit, est tout à fait inutile.

Non seulement vous n'avez pas besoin d'un CURSOR pour retourner un jeu de résultats, mais vous n'avez même pas besoin de la procédure, juste pour exécuter l'instruction SELECT.

Il suffit d'inclure le SELECT dans votre code PHP.

Answer 2

J'ai consulté votre conseil et enlevé le CURSEUR et les déclarations.

CREATE PROCEDURE get_task (IN var INT) 
BEGIN 

SELECT tq.`id_task`, tq.`job`, lts.`state_name`, ltt.`task_name`, tq.`worker_affected`, j.`user`, tq.`progress`, u.`name`, u.`phone`, u.`mobile`, u.`site`, w .`worker_name`, tq.`date_time_process_started`, tq.`frame` 
FROM `task_queue` tq 
LEFT JOIN `workers` w ON tq.`worker_affected` = w.`id_worker` 
     INNER JOIN `job` j ON tq.`job` = j.`job_id` 
     INNER JOIN `user` u ON j.`user` = u.`ipn` 
     INNER JOIN `list_task_type` ltt ON tq.`task_type` = ltt.`id_type_task` 
     INNER JOIN `list_task_state` lts ON tq.`task_state` = lts.`id_state` 
WHERE tq.`id_task` = var 
ORDER BY tq.`id_task`; 


END | 

En effet performances monté en flèche et maintenant ma procédure stockée est seulement deux fois plus lent que le script PHP (0,0006 vs 0,0012 secondes contre 0.0006s vs 0.009s précédemment). Et en voyant le code de la procédure stockée, je comprends pourquoi vous avez dit que c'était inutile, mais je vais le garder afin de forcer les utilisateurs de la base de données à travers les fonctions et procédures de leurs sites Web. Je me sens plus en sécurité comme ça.

Merci beaucoup.