What if you could let the database do the boring, repetitive row-by-row work for you?
Why Cursors for row iteration in MySQL? - Purpose & Use Cases
Imagine you have a huge list of customer orders in a spreadsheet, and you need to check each order one by one to apply a special discount. Doing this manually means opening each row, reading the data, and updating it yourself.
Manually checking and updating each row is slow and tiring. You might miss some rows or make mistakes. It's hard to keep track of where you left off, especially with thousands of rows.
Cursors let the database handle this row-by-row work for you. They act like a bookmark, moving through each row automatically so you can process data step-by-step without losing your place or making errors.
SELECT * FROM orders; -- Then manually check each row outside the database
DECLARE order_cursor CURSOR FOR SELECT * FROM orders; OPEN order_cursor; FETCH order_cursor INTO variables; -- Process each row inside the database CLOSE order_cursor;
With cursors, you can safely and efficiently handle complex row-by-row tasks inside the database itself.
A store wants to give a special gift to every customer who placed an order last month. Using a cursor, the database can go through each qualifying order and add a gift record automatically.
Manual row-by-row work is slow and error-prone.
Cursors automate moving through rows one at a time.
This makes complex data processing inside the database easier and safer.
Practice
Solution
Step 1: Understand cursor functionality
Cursors allow you to handle each row of a query result individually instead of all at once.Step 2: Identify the correct purpose
Processing rows one by one matches the cursor's main use, unlike speeding inserts or creating tables.Final Answer:
To process query results row by row -> Option CQuick Check:
Cursor = row-by-row processing [OK]
- Thinking cursors speed up inserts
- Confusing cursors with backup tools
- Assuming cursors create tables
Solution
Step 1: Recall cursor lifecycle
First, you declare the cursor, then open it to start fetching rows, and finally close it when done.Step 2: Match the correct sequence
Only DECLARE, OPEN, FETCH, CLOSE follows the correct order of cursor operations.Final Answer:
DECLARE, OPEN, FETCH, CLOSE -> Option BQuick Check:
Cursor order = DECLARE -> OPEN -> FETCH -> CLOSE [OK]
- Opening cursor before declaring
- Fetching before opening
- Closing before fetching all rows
DECLARE done INT DEFAULT FALSE;
DECLARE cur CURSOR FOR SELECT id FROM users;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
OPEN cur;
read_loop: LOOP
FETCH cur INTO @user_id;
IF done THEN
LEAVE read_loop;
END IF;
SELECT @user_id;
END LOOP;
CLOSE cur;What will this code output?
Solution
Step 1: Analyze cursor fetching loop
The cursor fetches each id from users table into @user_id, then prints it until no rows remain.Step 2: Understand handler and loop exit
The handler sets done = TRUE when no more rows, causing loop to exit properly after printing all ids.Final Answer:
It prints each user id from the users table one by one -> Option AQuick Check:
Cursor loop prints all rows one by one [OK]
- Assuming only first row prints
- Missing handler causes infinite loop
- Confusing session variables with local variables
DECLARE done INT DEFAULT FALSE;
DECLARE cur CURSOR FOR SELECT name FROM employees;
OPEN cur;
read_loop: LOOP
FETCH cur INTO @emp_name;
IF done THEN
LEAVE read_loop;
END IF;
SELECT @emp_name;
END LOOP;
CLOSE cur;What is the likely cause of the infinite loop?
Solution
Step 1: Check for handler presence
The code lacks a CONTINUE HANDLER to set done = TRUE when no more rows are fetched.Step 2: Understand loop exit condition
Without setting done = TRUE, the IF condition never triggers LEAVE, causing infinite loop.Final Answer:
Missing CONTINUE HANDLER to set done = TRUE when no rows left -> Option DQuick Check:
No handler = infinite loop [OK]
- Forgetting CONTINUE HANDLER
- Assuming loop exits automatically
- Misplacing variable declarations
DECLARE done INT DEFAULT FALSE;
DECLARE total_salary DECIMAL(10,2) DEFAULT 0;
DECLARE cur CURSOR FOR SELECT salary FROM employees;
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = TRUE;
OPEN cur;
read_loop: LOOP
FETCH cur INTO @sal;
IF done THEN
LEAVE read_loop;
END IF;
SET total_salary = total_salary + @sal;
END LOOP;
CLOSE cur;
SELECT total_salary;What is the expected output of this procedure?
Solution
Step 1: Verify declaration order and variables
All local variables (done, total_salary) are declared before the cursor and handler. FETCH INTO @sal uses a session variable, which is valid.Step 2: Trace execution
The loop fetches each salary, adds it to total_salary until the handler sets done=TRUE, then SELECT outputs the sum.Final Answer:
The sum of all employee salaries -> Option AQuick Check:
Cursor loop + handler + accumulation = total sum [OK]
- Declaring variables after cursors/handlers
- Thinking @vars require DECLARE
- Missing handler or wrong loop condition
Ready to prove it?
Pass the test and this pattern moves unknown
