Querying from views in MySQL - Time & Space Complexity
When we query data from a view in MySQL, it's important to understand how the time to get results grows as the data grows.
We want to know how the query's work changes when the underlying tables get bigger.
Analyze the time complexity of the following code snippet.
CREATE VIEW recent_orders AS
SELECT order_id, customer_id, order_date
FROM orders
WHERE order_date >= DATE_SUB(CURDATE(), INTERVAL 30 DAY);
SELECT * FROM recent_orders WHERE customer_id = 123;
This code creates a view showing orders from the last 30 days, then queries that view for a specific customer's orders.
Identify the loops, recursion, array traversals that repeat.
- Primary operation: Scanning the orders table rows that match the date condition.
- How many times: Once for each row in the orders table within the last 30 days.
As the number of recent orders grows, the query must check more rows to find those for the specific customer.
| Input Size (n) | Approx. Operations |
|---|---|
| 10 | About 10 rows scanned |
| 100 | About 100 rows scanned |
| 1000 | About 1000 rows scanned |
Pattern observation: The work grows roughly in direct proportion to the number of recent orders.
Time Complexity: O(n)
This means the time to get results grows linearly with the number of rows in the view.
[X] Wrong: "Querying a view is always faster than querying the table directly because it's pre-made."
[OK] Correct: A view is just a saved query. It runs fresh each time, so its speed depends on the underlying tables and filters.
Understanding how views affect query time helps you explain real database behavior clearly and confidently.
"What if the view included a join with another large table? How would that change the time complexity?"
Practice
Solution
Step 1: Understand the definition of a view
A view is not a physical table but a saved query that acts like a table.Step 2: Differentiate from other options
Options A, B, and C describe physical tables, backups, or users, which are not views.Final Answer:
A virtual table based on a stored query -> Option AQuick Check:
View = virtual table [OK]
- Thinking views store data physically
- Confusing views with backups
- Assuming views are user accounts
employee_view?Solution
Step 1: Recall standard SELECT syntax for views
Views are queried like tables using SELECT * FROM view_name;Step 2: Check each option's syntax
SELECT * FROM employee_view; uses correct syntax. Options B, C, and D use invalid keywords or order.Final Answer:
SELECT * FROM employee_view; -> Option CQuick Check:
SELECT * FROM view_name; is correct [OK]
- Using VIEW keyword in SELECT statement
- Replacing SELECT with GET
- Using SELECT ALL instead of SELECT *
sales_view defined as SELECT product_id, SUM(quantity) AS total_qty FROM sales GROUP BY product_id, what will the query SELECT * FROM sales_view WHERE total_qty > 100; return?Solution
Step 1: Understand the view definition
The view groups sales by product_id and sums quantity as total_qty.Step 2: Analyze the query on the view
The query filters rows where total_qty > 100, so it returns products with total sales over 100.Final Answer:
All products with total quantity sold greater than 100 -> Option AQuick Check:
Filtering on view columns works normally [OK]
- Thinking WHERE can't be used on views
- Confusing total_qty with original quantity column
- Assuming syntax error due to aggregation
customer_view defined as SELECT id, name, email FROM customers; but running SELECT phone FROM customer_view; gives an error. What is the problem?Solution
Step 1: Check the view's defined columns
The view only includes id, name, and email columns, no phone column.Step 2: Understand the error cause
Querying a column not in the view causes an error because it doesn't exist in the virtual table.Final Answer:
The column phone does not exist in the view -> Option BQuick Check:
Query columns must exist in view definition [OK]
- Assuming views allow any column selection
- Thinking views are corrupted if column missing
- Believing SELECT * is mandatory for views
active_users_view that shows only users with status = 'active' from the users table. Which query correctly creates this view?Solution
Step 1: Recall correct CREATE VIEW syntax
The syntax requires CREATE VIEW view_name AS SELECT ... WHERE ...Step 2: Check each option's correctness
CREATE VIEW active_users_view AS SELECT * FROM users WHERE status = 'active'; uses correct syntax with WHERE clause. CREATE VIEW active_users_view SELECT * FROM users WHERE status = 'active'; misses AS keyword. CREATE VIEW active_users_view AS SELECT * FROM users HAVING status = 'active'; wrongly uses HAVING without GROUP BY. CREATE VIEW active_users_view AS SELECT * FROM users WHERE status == 'active'; uses invalid '==' operator.Final Answer:
CREATE VIEW active_users_view AS SELECT * FROM users WHERE status = 'active'; -> Option DQuick Check:
CREATE VIEW ... AS SELECT ... WHERE ... is correct [OK]
- Omitting AS keyword
- Using HAVING without GROUP BY
- Using '==' instead of '=' in conditions
Ready to prove it?
Pass the test and this pattern moves unknown
