Trigger best practices and limitations in MySQL - Step-by-Step Execution

Concept Flow - Trigger best practices and limitations

Event occurs on table

↓

Trigger fires BEFORE or AFTER event

↓

Trigger executes defined SQL statements

↓

Changes applied or rolled back based on trigger logic

↓

Limitations checked: recursion, performance, privileges

↓

End of trigger execution

When a database event happens, the trigger runs SQL code before or after it, but must follow rules to avoid recursion and performance issues.

Execution Sample

MySQL

CREATE TRIGGER trg_before_insert
BEFORE INSERT ON employees
FOR EACH ROW
BEGIN
  SET NEW.created_at = NOW();
END;

This trigger sets the created_at timestamp automatically before a new employee record is inserted.

Execution Table

Step	Event	Trigger Timing	Action	Result
1	Insert new employee	BEFORE INSERT	Set NEW.created_at = NOW()	created_at set to current time
2	Insert continues	N/A	Row inserted with created_at	New employee record saved
3	Check for recursion	N/A	No recursive trigger calls	Execution proceeds
4	Check privileges	N/A	User has INSERT privilege	Trigger allowed
5	End	N/A	Trigger execution ends	Insert operation completes

💡 Trigger ends after setting timestamp and verifying no recursion or privilege issues

Variable Tracker

Variable	Start	After Step 1	After Step 2	Final
NEW.created_at	NULL	2024-06-01 12:00:00	2024-06-01 12:00:00	2024-06-01 12:00:00

Key Moments - 3 Insights

Why can't a trigger call itself recursively?

Because recursive triggers cause infinite loops and MySQL prevents this to protect database stability, as shown in step 3 of the execution table.

What happens if the user lacks privileges to run the trigger?

The trigger will not execute and the operation will fail, as checked in step 4 where privileges are verified.

Why is it best to keep trigger logic simple?

Complex triggers can slow down database operations and cause unexpected side effects, so keeping them simple ensures better performance and easier debugging.

Visual Quiz - 3 Questions

Look at the execution table, what action does the trigger perform at step 1?

A Checks user privileges

B Inserts the new employee record

C Sets NEW.created_at to current time

D Ends trigger execution

💡 Hint

Refer to the 'Action' column in step 1 of the execution table

At which step does the system check for recursive trigger calls?

A Step 2

B Step 3

C Step 4

D Step 5

💡 Hint

Look at the 'Step' and 'Action' columns for recursion checks

If the user does not have INSERT privileges, what happens according to the execution flow?

A Trigger execution is blocked and insert fails

B Trigger sets created_at anyway

C Trigger execution ends successfully

D Trigger runs after insert

💡 Hint

Check step 4 where privileges are verified before allowing trigger execution

Concept Snapshot

CREATE TRIGGER defines code to run BEFORE or AFTER table events.
Keep triggers simple to avoid performance issues.
Triggers cannot call themselves recursively.
User must have proper privileges for triggers to run.
Use triggers for automatic data changes like timestamps.

Full Transcript

A trigger in MySQL runs automatically before or after a table event like INSERT. It executes SQL code such as setting timestamps. The trigger must not call itself recursively to avoid infinite loops. The user must have the right privileges for the trigger to run. Keeping trigger logic simple helps maintain good performance and avoids unexpected problems. The example trigger sets the created_at field before inserting a new employee record.

Practice

1. Which of the following is a best practice when creating MySQL triggers?

easy

A. Keep trigger logic simple to avoid performance issues.

B. Use triggers to replace all application logic.

C. Allow triggers to call themselves recursively without limits.

D. Write triggers that perform complex calculations on large datasets.

Solution

1. Step 1: Understand trigger performance impact

   Triggers run automatically on data changes, so complex logic can slow down database operations.

2. Step 2: Identify best practice for trigger design

   Keeping trigger logic simple helps maintain good performance and avoids unexpected delays.

3. Final Answer:

   Keep trigger logic simple to avoid performance issues. -> Option A

4. Quick Check:

   Simple trigger logic = Better performance [OK]

Hint: Keep triggers simple to avoid slowdowns [OK]

Common Mistakes:

• Trying to put all business logic inside triggers
• Allowing infinite recursion in triggers
• Using triggers for heavy data processing

2. Which syntax correctly defines a BEFORE INSERT trigger in MySQL?

easy

A. CREATE TRIGGER trg BEFORE INSERT ON table_name FOR EACH ROW BEGIN ... END;

B. CREATE TRIGGER trg AFTER INSERT ON table_name FOR EACH ROW BEGIN ... END;

C. CREATE TRIGGER trg BEFORE UPDATE ON table_name FOR EACH ROW BEGIN ... END;

D. CREATE TRIGGER trg BEFORE DELETE ON table_name FOR EACH ROW BEGIN ... END;

Solution

1. Step 1: Identify trigger timing and event

   BEFORE INSERT triggers run before a new row is inserted.

2. Step 2: Match syntax to BEFORE INSERT event

   CREATE TRIGGER trg BEFORE INSERT ON table_name FOR EACH ROW BEGIN ... END; uses BEFORE INSERT, correct timing and event for this trigger.

3. Final Answer:

   CREATE TRIGGER trg BEFORE INSERT ON table_name FOR EACH ROW BEGIN ... END; -> Option A

4. Quick Check:

   BEFORE INSERT syntax = CREATE TRIGGER trg BEFORE INSERT ON table_name FOR EACH ROW BEGIN ... END; [OK]

Hint: BEFORE triggers run before data changes [OK]

Common Mistakes:

• Confusing BEFORE and AFTER keywords
• Using wrong event like UPDATE or DELETE
• Missing FOR EACH ROW clause

3. Given this trigger, what happens when a new row is inserted?

CREATE TRIGGER trg BEFORE INSERT ON employees FOR EACH ROW BEGIN SET NEW.salary = NEW.salary * 1.1; END;

medium

A. The trigger causes a syntax error.

B. The salary is increased by 10% before insertion.

C. The salary remains unchanged.

D. The insertion fails due to recursion.

Solution

1. Step 1: Analyze trigger action on BEFORE INSERT

   The trigger modifies the NEW.salary value by multiplying it by 1.1 before the row is inserted.

2. Step 2: Understand effect on inserted data

   The inserted row will have salary increased by 10% automatically.

3. Final Answer:

   The salary is increased by 10% before insertion. -> Option B

4. Quick Check:

   BEFORE INSERT modifies NEW.salary = increased salary [OK]

Hint: BEFORE triggers can modify NEW row data [OK]

Common Mistakes:

• Thinking triggers run after insertion
• Assuming salary stays the same
• Confusing NEW and OLD keywords

4. What is wrong with this trigger definition?

CREATE TRIGGER trg AFTER UPDATE ON employees FOR EACH ROW BEGIN UPDATE employees SET salary = salary * 1.05 WHERE id = NEW.id; END;

medium

A. It will not update any rows because NEW.id is invalid.

B. Syntax error due to missing DELIMITER statement.

C. Triggers cannot use UPDATE statements inside their body.

D. It causes infinite recursion by updating the same table inside the trigger.

Solution

1. Step 1: Identify trigger action on AFTER UPDATE

   The trigger updates the same table employees inside an AFTER UPDATE trigger.

2. Step 2: Understand recursion risk

   Updating the same table inside its own UPDATE trigger causes the trigger to call itself repeatedly, causing infinite recursion.

3. Final Answer:

   It causes infinite recursion by updating the same table inside the trigger. -> Option D

4. Quick Check:

   Trigger updating same table = recursion risk [OK]

Hint: Avoid updating same table inside its trigger [OK]

Common Mistakes:

• Ignoring recursion risk
• Assuming syntax error without DELIMITER
• Thinking triggers can't run UPDATE statements

5. You want to log every DELETE action on the orders table without slowing down the delete operation. Which trigger design is best?

hard

A. Use a BEFORE DELETE trigger that updates the orders table with a log message.

B. Use an AFTER DELETE trigger that updates the orders table itself.

C. Use an AFTER DELETE trigger that inserts a log record into a separate table.

D. Use a BEFORE DELETE trigger that performs complex calculations before deleting.

Solution

1. Step 1: Choose trigger timing for logging

   AFTER DELETE triggers run after the row is deleted, so they don't block the delete operation.

2. Step 2: Select action that avoids slowing delete

   Inserting a log record into a separate table is efficient and safe, avoiding recursion or delays.

3. Final Answer:

   Use an AFTER DELETE trigger that inserts a log record into a separate table. -> Option C

4. Quick Check:

   AFTER DELETE + separate log table = best practice [OK]

Hint: Log deletes AFTER action to avoid delays [OK]

Common Mistakes:

• Updating same table inside trigger causing recursion
• Using BEFORE DELETE for logging causing delays
• Doing heavy calculations inside triggers