Creating stored procedures in MySQL - Performance & Efficiency
When we create stored procedures in MySQL, we want to know how the time it takes to run them changes as the data grows.
We ask: How does the work inside the procedure grow when there are more rows or calls?
Analyze the time complexity of the following stored procedure.
CREATE PROCEDURE GetUserOrders(IN userId INT)
BEGIN
SELECT * FROM orders WHERE customer_id = userId;
END;
This procedure fetches all orders for a given user from the orders table.
Look for loops or repeated work inside the procedure.
- Primary operation: Scanning the orders table to find matching rows.
- How many times: The database checks each order row to see if it belongs to the user.
As the number of orders grows, the work to find matching orders grows too.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 checks |
| 100 | About 100 checks |
| 1000 | About 1000 checks |
Pattern observation: The work grows roughly in direct proportion to the number of orders.
Time Complexity: O(n)
This means the time to run the procedure grows linearly with the number of orders in the table.
[X] Wrong: "Stored procedures always run instantly no matter how much data there is."
[OK] Correct: The procedure still does work on the data, so if the data grows, the time to run grows too.
Understanding how stored procedures scale helps you write efficient database code and explain your reasoning clearly in interviews.
What if the procedure included a loop inside that called another query for each order? How would the time complexity change?
Practice
Solution
Step 1: Understand stored procedure concept
A stored procedure is a saved set of SQL commands that can be run multiple times without rewriting.Step 2: Compare options with definition
Only To save a set of SQL commands for reuse later correctly describes this purpose; others describe unrelated tasks.Final Answer:
To save a set of SQL commands for reuse later -> Option BQuick Check:
Stored procedure = saved SQL commands [OK]
- Confusing stored procedures with database creation
- Thinking stored procedures delete tables
- Assuming stored procedures backup data
GetUsers without parameters?Solution
Step 1: Recall correct stored procedure syntax
MySQL requires parentheses for parameters (empty if none), BEGIN and END to mark procedure body.Step 2: Check each option
CREATE PROCEDURE GetUsers() BEGIN SELECT * FROM users; END; uses parentheses and BEGIN...END correctly. Others miss parentheses, BEGIN/END, or use wrong braces.Final Answer:
CREATE PROCEDURE GetUsers() BEGIN SELECT * FROM users; END; -> Option DQuick Check:
Syntax needs () and BEGIN...END [OK]
- Omitting parentheses after procedure name
- Missing BEGIN and END keywords
- Using curly braces instead of BEGIN...END
CREATE PROCEDURE AddNumbers(IN a INT, IN b INT, OUT sum INT) BEGIN SET sum = a + b; END;
What will be the value of
sum after calling CALL AddNumbers(3, 5, @result); SELECT @result;?Solution
Step 1: Understand procedure parameters and call
The procedure takes two input integers a and b, and outputs their sum into the OUT parameter sum.Step 2: Analyze the call and output
Calling with 3 and 5 sets sum = 3 + 5 = 8. The OUT parameter is stored in @result, so SELECT @result returns 8.Final Answer:
8 -> Option AQuick Check:
3 + 5 = 8 [OK]
- Confusing concatenation with addition
- Expecting sum to be NULL before assignment
- Forgetting to use user variable for OUT parameter
CREATE PROCEDURE GetCount() BEGIN SELECT COUNT(*) FROM users END;
Solution
Step 1: Check syntax inside procedure body
Each statement inside BEGIN...END must end with a semicolon in MySQL.Step 2: Identify missing semicolon
The SELECT COUNT(*) FROM users statement lacks a semicolon before END; causing syntax error.Final Answer:
Missing semicolon after SELECT statement -> Option AQuick Check:
Statements inside BEGIN...END need semicolons [OK]
- Omitting semicolon after SQL statements
- Thinking parentheses are not allowed in procedure name
- Believing COUNT(*) is invalid
UpdateSalary that increases an employee's salary by a given percentage. Which of the following is the correct way to write it?Solution
Step 1: Check parameter declarations and body structure
CREATE PROCEDURE UpdateSalary(IN empId INT, IN pct DECIMAL(5,2)) BEGIN UPDATE employees SET salary = salary * (1 + pct/100) WHERE id = empId; END; correctly declares input parameters with IN and uses BEGIN...END block.Step 2: Verify salary update logic and syntax
CREATE PROCEDURE UpdateSalary(IN empId INT, IN pct DECIMAL(5,2)) BEGIN UPDATE employees SET salary = salary * (1 + pct/100) WHERE id = empId; END; updates salary by multiplying with (1 + pct/100), which correctly increases salary by percentage. It also ends statements with semicolon.Step 3: Identify errors in other options
CREATE PROCEDURE UpdateSalary(empId INT, pct DECIMAL(5,2)) BEGIN UPDATE employees SET salary = salary + pct WHERE id = empId; END; lacks IN keywords and adds pct directly (not percentage). CREATE PROCEDURE UpdateSalary(IN empId INT, IN pct INT) UPDATE employees SET salary = salary * pct WHERE id = empId; misses BEGIN...END and uses wrong pct type. CREATE PROCEDURE UpdateSalary(IN empId INT, IN pct DECIMAL(5,2)) BEGIN UPDATE employees SET salary = salary + pct WHERE id = empId END misses semicolon before END.Final Answer:
CREATE PROCEDURE UpdateSalary(IN empId INT, IN pct DECIMAL(5,2)) BEGIN UPDATE employees SET salary = salary * (1 + pct/100) WHERE id = empId; END; -> Option CQuick Check:
Use IN params, BEGIN...END, and correct percentage formula [OK]
- Forgetting IN keyword for parameters
- Adding percentage directly instead of multiplying
- Missing BEGIN...END or semicolons
Ready to prove it?
Pass the test and this pattern moves unknown
