MySQL简单选择 - 存储过程的性能

我目前正在开发一个MySQL存储过程，我期待着速度略有增加。但是，当我通过PHP脚本将它与SQL请求执行进行比较时，PHP速度更快。一个1000行的表格大约快10倍，而6000行的表格大约快两倍。MySQL简单选择 - 存储过程的性能

表的大小是否提高了程序的性能？我在代码中犯了一个错误，我可以优化它吗？

我的配置是MySQL 5.0.10上的MyIsam引擎。我的存储过程是

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 |

来源

2013-04-26 Bastien

请勿使用游标。 – Devart 2013-04-26 15:43:15

如果只有一行使用SELECT INTO语句。 – Sebas 2013-04-26 18:14:05

您写入的存储过程是完全不必要的。

您不仅需要CURSOR来返回结果集，您甚至不需要该过程，只需运行单个SELECT语句。

只需在您的PHP代码中包含SELECT。

来源

2013-04-26 18:08:32

我翻阅了你的建议并删除了CURSOR和声明。

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 |

事实上演出身价暴涨，现在我的存储过程只比PHP脚本（针对0.0006s VS 0.009s以前0.0006 VS0.0012秒）的两倍慢。

并看到存储过程的代码我明白你为什么说它没用，但我会保留它，以强制数据库用户通过其网站中的功能和过程。我觉得这样更安全。

非常感谢。

来源

2013-05-03 08:10:09 Bastien

在存储过程中封装一个'SELECT'似乎是不必要的复杂性和开销，除非你想从表中SELECT [SELECT]，用户没有'SELECT'权限（并且你使用'SQL SECURITY DEFINER'）。 – 2013-05-03 15:21:31

MySQL简单选择 - 存储过程的性能

回答

相关问题