ACID properties in MySQL - Time & Space Complexity
We want to understand how the time cost of database transactions changes as the amount of data grows.
Specifically, how the ACID properties affect the work done during transactions.
Analyze the time complexity of a transaction ensuring ACID properties.
START TRANSACTION;
UPDATE accounts SET balance = balance - 100 WHERE id = 1;
UPDATE accounts SET balance = balance + 100 WHERE id = 2;
COMMIT;
This code transfers money between two accounts within a transaction that must be atomic, consistent, isolated, and durable.
Look for repeated actions that affect time cost.
- Primary operation: Two UPDATE statements on specific rows.
- How many times: Each UPDATE runs once per transaction regardless of data size.
The transaction updates fixed rows, so the number of operations stays the same even if the table grows.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 rows | 2 updates |
| 1000 rows | 2 updates |
| 1,000,000 rows | 2 updates |
Pattern observation: The work does not increase with table size because only specific rows are updated.
Time Complexity: O(1)
This means the time to complete the transaction stays about the same no matter how big the table is.
[X] Wrong: "Because the table is large, the transaction will take longer every time."
[OK] Correct: The transaction only changes a fixed number of rows, so the size of the whole table does not affect the time much.
Understanding how ACID transactions scale helps you explain database behavior clearly and confidently in real-world situations.
"What if the transaction updated every row in the table? How would the time complexity change?"
Practice
Solution
Step 1: Recall the ACID properties
ACID stands for Atomicity, Consistency, Isolation, and Durability.Step 2: Identify the incorrect option
Durability and Speed adds "Speed" which is not part of ACID properties.Final Answer:
Durability and Speed -> Option AQuick Check:
ACID excludes Speed [OK]
- Confusing performance terms with ACID properties
- Thinking Speed is part of ACID
- Mixing up Isolation with Integrity
Solution
Step 1: Recall MySQL transaction syntax
MySQL usesSTART TRANSACTION;to begin a transaction.Step 2: Check other options
Options A, B, and D are not valid MySQL commands for starting transactions.Final Answer:
START TRANSACTION; -> Option BQuick Check:
MySQL uses START TRANSACTION [OK]
- Using BEGIN TRANSACTION which is not valid in MySQL
- Confusing with other SQL dialects
- Typing incorrect keywords like OPEN or INIT
START TRANSACTION; UPDATE accounts SET balance = balance - 100 WHERE id = 1; UPDATE accounts SET balance = balance + 100 WHERE id = 2; COMMIT;
What ACID property does this sequence mainly demonstrate?
Solution
Step 1: Understand the transaction sequence
The two updates are grouped inside a transaction with COMMIT at the end.Step 2: Identify the ACID property
Atomicity ensures either both updates happen or none do, preventing partial changes.Final Answer:
Atomicity - all changes happen or none -> Option DQuick Check:
Transaction groups changes atomically [OK]
- Confusing Isolation with Atomicity
- Thinking Durability means temporary changes
- Assuming Consistency only checks data types
START TRANSACTION; UPDATE inventory SET quantity = quantity - 5 WHERE product_id = 10; COMMIT;
But sometimes the quantity becomes negative. What ACID property is likely violated?
Solution
Step 1: Analyze the problem
Quantity becoming negative means data rules are broken.Step 2: Identify violated ACID property
Consistency ensures data stays valid and follows rules; here it is violated.Final Answer:
Consistency -> Option AQuick Check:
Consistency keeps data valid [OK]
- Thinking Atomicity prevents negative values
- Confusing Isolation with data validity
- Assuming Durability fixes data rules
Transaction 1: START TRANSACTION; UPDATE accounts SET balance = balance - 50 WHERE id = 1; -- waits before COMMIT Transaction 2: START TRANSACTION; SELECT balance FROM accounts WHERE id = 1; COMMIT;
Which ACID property ensures Transaction 2 does not see the uncommitted balance change from Transaction 1?
Solution
Step 1: Understand concurrent transactions
Transaction 1 updates but delays commit; Transaction 2 reads the same data.Step 2: Identify ACID property controlling visibility
Isolation ensures uncommitted changes are hidden from other transactions.Final Answer:
Isolation -> Option CQuick Check:
Isolation hides uncommitted changes [OK]
- Confusing Isolation with Atomicity
- Thinking Durability controls visibility
- Assuming Consistency hides uncommitted data
Ready to prove it?
Pass the test and this pattern moves unknown
