Trigger best practices and limitations in MySQL - Practice Problems & Coding Challenges

Challenge - 5 Problems

🧠 Conceptual

intermediate

When to avoid using triggers in MySQL?

Which of the following is a recommended reason to avoid using triggers in MySQL?

A When you want to keep business logic simple and maintainable by avoiding hidden side effects

B When you need to enforce data integrity at the database level

C When you want to automatically update audit columns like last_modified

D When you want to replicate data changes to another table automatically

💡 Hint

Think about how triggers can affect code readability and debugging.

Triggers can cause hidden side effects that make debugging and maintenance harder. Keeping business logic explicit in application code is often better.

❓ query_result

intermediate

Output of a BEFORE INSERT trigger modifying data

Given this table and trigger, what will be the value of the 'name' column after inserting ('john')? Table: users(id INT AUTO_INCREMENT PRIMARY KEY, name VARCHAR(50)) Trigger: CREATE TRIGGER before_insert_users BEFORE INSERT ON users FOR EACH ROW SET NEW.name = UPPER(NEW.name);

MySQL

INSERT INTO users (name) VALUES ('john');
SELECT name FROM users WHERE id = LAST_INSERT_ID();

A 'john'

B Syntax error in trigger

C NULL

D 'JOHN'

💡 Hint

BEFORE INSERT triggers can modify the data before it is saved.

The trigger converts the 'name' to uppercase before inserting, so the stored value is 'JOHN'.

📝 Syntax

advanced

Identify the syntax error in this trigger definition

Which option contains a syntax error in the MySQL trigger definition?

MySQL

CREATE TRIGGER trg_after_update
AFTER UPDATE ON employees
FOR EACH ROW
BEGIN
  IF NEW.salary < OLD.salary THEN
    SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = 'Salary cannot decrease';
  END IF;
END;

A Missing delimiter change before trigger creation

B FOR EACH ROW should be FOR EACH STATEMENT

C SIGNAL SQLSTATE is not allowed in triggers

D Trigger name cannot contain underscores

💡 Hint

MySQL requires changing the delimiter when defining triggers with BEGIN...END blocks.

MySQL needs the delimiter changed before creating triggers with multiple statements to avoid premature end of the statement.

❓ optimization

advanced

Best practice to avoid performance issues with triggers

Which practice helps avoid performance problems caused by triggers in MySQL?

A Use triggers to replace all application-level validations

B Keep trigger logic simple and avoid complex queries inside triggers

C Create multiple triggers for the same event to split logic

D Use triggers to perform heavy data aggregation on large tables

💡 Hint

Think about how triggers run synchronously during data changes.

Complex or heavy queries inside triggers slow down data modification operations. Keeping triggers simple improves performance.

🔧 Debug

expert

Why does this trigger cause an infinite loop?

Consider this trigger: CREATE TRIGGER trg_after_update AFTER UPDATE ON orders FOR EACH ROW BEGIN UPDATE orders SET status = 'processed' WHERE id = NEW.id; END; Why does this trigger cause an infinite loop?

A Because the trigger syntax is invalid and causes repeated errors

B Because AFTER UPDATE triggers cannot modify the same table

C Because the UPDATE inside the trigger fires the same trigger again repeatedly

D Because the trigger does not have a WHERE clause

💡 Hint

Think about what happens when a trigger updates the same table it listens to.

The UPDATE inside the trigger causes the trigger to fire again, creating an infinite loop of updates.

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