AFTER UPDATE triggers in MySQL - Time & Space Complexity

Time Complexity: AFTER UPDATE triggers

O(n)

Understanding Time Complexity

When using AFTER UPDATE triggers in MySQL, it's important to understand how the time to run the trigger grows as more rows are updated.

We want to know how the trigger's work scales with the number of updated rows.

Scenario Under Consideration

Analyze the time complexity of the following AFTER UPDATE trigger.

CREATE TRIGGER update_log AFTER UPDATE ON employees
FOR EACH ROW
BEGIN
  INSERT INTO audit_log(employee_id, changed_at) VALUES (NEW.id, NOW());
END;
    

This trigger adds a record to an audit_log table every time a row in employees is updated.

Identify Repeating Operations

Look at what repeats when the trigger runs.

• Primary operation: The trigger runs once for each updated row.
• How many times: Equal to the number of rows updated in the employees table.

How Execution Grows With Input

As more rows are updated, the trigger runs more times.

Input Size (n)	Approx. Operations
10	10 inserts into audit_log
100	100 inserts into audit_log
1000	1000 inserts into audit_log

Pattern observation: The work grows directly with the number of updated rows.

Final Time Complexity

Time Complexity: O(n)

This means the time to complete the trigger grows linearly with the number of rows updated.

Common Mistake

[X] Wrong: "The trigger runs only once no matter how many rows are updated."

[OK] Correct: In MySQL, AFTER UPDATE triggers run once per row, so the work repeats for each updated row, not just once.

Interview Connect

Understanding how triggers scale helps you design efficient database operations and shows you can think about performance in real projects.

Self-Check

What if the trigger updated another table instead of inserting? How would that affect the time complexity?

Practice

1. What is the main purpose of an AFTER UPDATE trigger in MySQL?

easy

A. To execute actions automatically after a row is updated in a table

B. To prevent updates from happening on a table

C. To execute actions before a row is inserted

D. To delete rows after an update

Solution

1. Step 1: Understand trigger timing

   An AFTER UPDATE trigger runs after a row in a table is updated.

2. Step 2: Identify trigger purpose

   Its purpose is to perform extra actions automatically after the update, like logging or updating related data.

3. Final Answer:

   To execute actions automatically after a row is updated in a table -> Option A

4. Quick Check:

   AFTER UPDATE triggers run after update [OK]

Hint: AFTER UPDATE triggers run after row changes [OK]

Common Mistakes:

• Confusing AFTER UPDATE with BEFORE UPDATE
• Thinking triggers prevent updates
• Mixing trigger types like INSERT or DELETE

2. Which of the following is the correct syntax to create an AFTER UPDATE trigger on a table named employees?

easy

A. CREATE TRIGGER trg AFTER INSERT ON employees FOR EACH ROW BEGIN END;

B. CREATE TRIGGER trg AFTER UPDATE ON employees FOR EACH ROW BEGIN END;

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

D. CREATE TRIGGER trg AFTER UPDATE employees FOR EACH ROW BEGIN END;

Solution

1. Step 1: Check trigger timing and event

   The trigger must be AFTER UPDATE on the employees table.

2. Step 2: Verify syntax correctness

   CREATE TRIGGER trg AFTER UPDATE ON employees FOR EACH ROW BEGIN END; uses correct syntax: CREATE TRIGGER trg AFTER UPDATE ON employees FOR EACH ROW BEGIN END;

3. Final Answer:

   CREATE TRIGGER trg AFTER UPDATE ON employees FOR EACH ROW BEGIN END; -> Option B

4. Quick Check:

   Correct syntax includes 'AFTER UPDATE ON table' [OK]

Hint: Syntax: CREATE TRIGGER name AFTER UPDATE ON table [OK]

Common Mistakes:

• Omitting ON keyword before table name
• Using BEFORE instead of AFTER
• Using wrong event like INSERT

3. Given this trigger on table products:

CREATE TRIGGER trg_after_update
AFTER UPDATE ON products
FOR EACH ROW
BEGIN
  INSERT INTO audit_log (product_id, old_price, new_price)
  VALUES (OLD.id, OLD.price, NEW.price);
END;

What happens when a product's price is updated?

medium

A. The audit_log table is deleted

B. The product's price is reverted to the old price

C. The update is blocked and no changes happen

D. A new row is added to audit_log with old and new prices

Solution

1. Step 1: Understand trigger action

   The trigger inserts a row into audit_log after a product update.

2. Step 2: Analyze inserted values

   It records OLD.id, OLD.price, and NEW.price to log price changes.

3. Final Answer:

   A new row is added to audit_log with old and new prices -> Option D

4. Quick Check:

   AFTER UPDATE triggers can log changes [OK]

Hint: AFTER UPDATE can log old and new values [OK]

Common Mistakes:

• Thinking trigger changes original update
• Confusing OLD and NEW values
• Assuming trigger blocks update

4. You wrote this trigger but get an error:

CREATE TRIGGER trg AFTER UPDATE ON orders
FOR EACH ROW
BEGIN
  SET NEW.status = 'processed';
END;

What is the problem?

medium

A. The syntax for SET is incorrect inside triggers

B. The trigger must be BEFORE UPDATE to modify NEW values

C. You cannot modify NEW values in an AFTER UPDATE trigger

D. Triggers cannot use BEGIN...END blocks

Solution

1. Step 1: Understand trigger timing restrictions

   In AFTER UPDATE triggers, NEW values are read-only and cannot be changed.

2. Step 2: Identify correct timing to modify NEW

   To modify NEW values, use BEFORE UPDATE triggers instead.

3. Final Answer:

   You cannot modify NEW values in an AFTER UPDATE trigger -> Option C

4. Quick Check:

   AFTER UPDATE triggers cannot change NEW row [OK]

Hint: Modify NEW only in BEFORE UPDATE triggers [OK]

Common Mistakes:

• Trying to change NEW in AFTER UPDATE triggers
• Confusing BEFORE and AFTER triggers
• Incorrect SET syntax blamed

5. You want to keep a count of how many times each user's email was updated in a table users. Which trigger code correctly updates a email_update_count column after each email change?

hard

A. CREATE TRIGGER trg_email_update
BEFORE UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.email != NEW.email THEN
SET NEW.email_update_count = OLD.email_update_count + 1;
END IF;
END;

B. CREATE TRIGGER trg_email_update
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.email != NEW.email THEN
UPDATE users SET email_update_count = email_update_count + 1 WHERE id = NEW.id;
END IF;
END;

C. CREATE TRIGGER trg_email_update
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
SET NEW.email_update_count = OLD.email_update_count + 1;
END;

D. CREATE TRIGGER trg_email_update
AFTER UPDATE ON users
FOR EACH ROW
BEGIN
IF OLD.email = NEW.email THEN
UPDATE users SET email_update_count = email_update_count + 1 WHERE id = NEW.id;
END IF;
END;

Solution

1. Step 1: Identify when to modify the count

   The count should increase only if the email changes, so check if OLD.email != NEW.email.

2. Step 2: Choose correct trigger timing to modify NEW

   To change email_update_count in the same row, use a BEFORE UPDATE trigger and set NEW.email_update_count.

3. Step 3: Analyze options

   CREATE TRIGGER trg_email_update
   BEFORE UPDATE ON users
   FOR EACH ROW
   BEGIN
     IF OLD.email != NEW.email THEN
       SET NEW.email_update_count = OLD.email_update_count + 1;
     END IF;
   END;

   correctly uses BEFORE UPDATE, compares emails, and sets NEW value.

   CREATE TRIGGER trg_email_update
   AFTER UPDATE ON users
   FOR EACH ROW
   BEGIN
     IF OLD.email != NEW.email THEN
       UPDATE users SET email_update_count = email_update_count + 1 WHERE id = NEW.id;
     END IF;
   END;

   tries to update the same table in AFTER UPDATE, causing recursion.

   CREATE TRIGGER trg_email_update
   AFTER UPDATE ON users
   FOR EACH ROW
   BEGIN
     SET NEW.email_update_count = OLD.email_update_count + 1;
   END;

   tries to set NEW in AFTER UPDATE (not allowed).

   CREATE TRIGGER trg_email_update
   AFTER UPDATE ON users
   FOR EACH ROW
   BEGIN
     IF OLD.email = NEW.email THEN
       UPDATE users SET email_update_count = email_update_count + 1 WHERE id = NEW.id;
     END IF;
   END;

   updates count when emails are equal (wrong logic).

4. Final Answer:

   BEFORE UPDATE trigger that sets NEW.email_update_count if OLD.email != NEW.email -> Option A

5. Quick Check:

   Modify NEW in BEFORE UPDATE triggers [OK]

Hint: Change NEW only in BEFORE UPDATE, check OLD vs NEW values [OK]

Common Mistakes:

• Trying to modify NEW in AFTER UPDATE triggers
• Updating the same table inside AFTER UPDATE causing recursion
• Wrong condition logic for email change