MySQL Stored Procedure Programming

Cursors

When you need to retrieve only a single row from a SELECT statement, using the INTO clause is far easier than declaring, opening, fetching from, and closing a cursor. But does the INTO clause generate some additional work for MySQL or could the INTO clause be more efficient than a cursor? In other words, which of the two stored programs shown in Example 22-20 is more efficient?

Example 22-20. Two equivalent stored programs, one using INTO and the other using a cursor

CREATE PROCEDURE using_into
       ( p_customer_id INT,OUT p_customer_name VARCHAR(30))
    READS SQL DATA
BEGIN
        SELECT customer_name
          INTO p_customer_name
          FROM customers
         WHERE customer_id=p_customer_id;
END;

CREATE PROCEDURE using_cursor
    (p_customer_id INT,OUT  p_customer_name VARCHAR(30))
    READS SQL DATA
BEGIN

    DECLARE cust_csr CURSOR FOR
         SELECT customer_name
           FROM customers
          WHERE customer_id=p_customer_id;

        OPEN cust_csr;
        FETCH cust_csr INTO p_customer_name;
        CLOSE cust_csr;

END;

Certainly, it is simpler to code an INTO statement than to code DECLARE, OPEN, FETCH, and CLOSE statements, and we will probably only bother to do this—when we know that the SQL returns only one row—if there is a specific performance advantage. As it turns out, there is actually a slight performance penalty for using an explicit cursor. Figure 22-10 shows the relative performance of each of the stored programs in Example 22-20—over 11,000 executions, the INTO-based stored program was approximately 15% faster than the stored program that used an explicit ...