Top 50 SQL & RDBMS Interview Questions with Answers (2026): Beginner to SQL Expert

💡 Why Interviewers Ask This: The ultimate baseline test. You must explicitly mention that SQL is used for relational (tabular) databases — not NoSQL. This distinction is what they are checking for.

💡 Why Interviewers Ask This: To ensure you understand the difference between a programming language specification (SQL) and a database engine implementation (MySQL). Many beginners confuse the two.

💡 Why Interviewers Ask This: Highly tested. Classic trap: if an interviewer asks what type of command TRUNCATE is, the answer is DDL — not DML. Beginners always say DML.

A Primary Key is a constraint that uniquely identifies each row in a database table. Rules: (1) All values must be unique — no two rows can share the same primary key. (2) It cannot contain a NULL value. (3) A table can have only one primary key (though it can be composite — spanning multiple columns). It is typically implemented as a clustered index, physically ordering the table data.

💡 Why Interviewers Ask This: The most fundamental constraint in database design. Explicitly mention: unique, no NULLs, only one per table. These three rules are the expected answer.

A Foreign Key is a column (or group of columns) in one table that references the Primary Key of another table, creating a link between the two. It enforces referential integrity — ensuring you cannot insert a value in the foreign key column that doesn't exist in the referenced parent table, and (depending on configuration) controlling what happens when a parent row is deleted or updated.

💡 Why Interviewers Ask This: Tests your knowledge of relational mapping. The expected follow-up is about ON DELETE CASCADE vs ON DELETE RESTRICT — know both behaviours.

💡 Why Interviewers Ask This: The classic PK vs Unique comparison. The ability to accept a NULL value is the critical differentiator that trips up candidates.

A NULL value represents a missing, unknown, or inapplicable value in a column. It is not the same as zero (0), an empty string (''), or false. Critical rules: (1) Checking for NULL requires IS NULL or IS NOT NULL — using = NULL in a WHERE clause will never return results because NULL = NULL evaluates to UNKNOWN (not TRUE). (2) Most aggregate functions automatically ignore NULL values (except COUNT(*)).

💡 Why Interviewers Ask This: NULLs cause catastrophic bugs in production. The key insight: NULL = NULL is UNKNOWN, not TRUE. You must use IS NULL.

💡 Why Interviewers Ask This: The most frequently asked filtering question in SQL interviews. Memorize the execution order: WHERE → GROUP BY → HAVING.

The GROUP BY statement groups rows with the same values in specified columns into summary rows, collapsing multiple rows into one per group. It is almost always used with aggregate functions like COUNT(), SUM(), AVG(), MAX(), or MIN() to perform calculations on each group. Example: SELECT Department, COUNT(*) FROM Employees GROUP BY Department — returns one row per department with the employee count.

💡 Why Interviewers Ask This: Essential for all data analysis and reporting roles. Know that every column in SELECT that is not an aggregate function must appear in the GROUP BY clause.

The ORDER BY clause sorts the result-set in ascending (ASC) or descending (DESC) order based on one or more columns. By default, ORDER BY sorts in ascending order — you must explicitly write DESC for descending. It is the last clause evaluated in a query (after WHERE and HAVING), so it can reference column aliases defined in SELECT.

💡 Why Interviewers Ask This: Basic syntax knowledge. The key fact: ASC is the default and can be omitted. DESC must always be explicit.

The IN operator allows you to specify multiple values in a WHERE clause as a shorthand for multiple OR conditions. Example: WHERE Status IN ('Shipped', 'Processing', 'Delivered') is equivalent to WHERE Status = 'Shipped' OR Status = 'Processing' OR Status = 'Delivered'. IN can also take a subquery: WHERE UserID IN (SELECT UserID FROM PremiumUsers).

💡 Why Interviewers Ask This: Tests your ability to write clean, readable queries. Also sets up the IN vs EXISTS performance comparison question — EXISTS is faster for large subquery results.

The BETWEEN operator selects values within a given range (inclusive on both ends). Values can be numbers, text, or dates. Example: WHERE Price BETWEEN 10 AND 20 returns rows where Price is 10, 20, or any value in between. NOT BETWEEN excludes the range. For dates: WHERE OrderDate BETWEEN '2026-01-01' AND '2026-03-31'.

💡 Why Interviewers Ask This: Often asked with date filtering. Critical fact: both boundary values (10 and 20) are included in the result — it is inclusive.

💡 Why Interviewers Ask This: Essential for text search. Performance note: LIKE '%value%' (leading wildcard) cannot use an index and causes a full table scan.

The DISTINCT keyword in a SELECT statement returns only unique (non-duplicate) values, filtering out any duplicate rows from the result set. Example: SELECT DISTINCT Department FROM Employees returns each department name exactly once, regardless of how many employees are in it. Performance note: DISTINCT requires a sort or hash operation to deduplicate — it is more expensive than a plain SELECT. Use GROUP BY as an alternative when you also need aggregation.

💡 Why Interviewers Ask This: Practical data-cleaning test. DISTINCT operates on the entire row, not just one column — if multiple columns are selected, all combinations are deduplicated together.

A JOIN clause combines rows from two or more tables based on a related column between them — typically a Foreign Key in one table matching the Primary Key of another. JOINs are the fundamental mechanism that makes relational databases "relational" — they let you query data spread across multiple normalized tables in a single statement. Without JOINs, you would need to run multiple queries and merge the results manually in application code.

💡 Why Interviewers Ask This: The bread and butter of relational databases. The follow-up is always naming the types. Know: INNER, LEFT, RIGHT, FULL OUTER, CROSS, and SELF.

An INNER JOIN returns only the rows that have matching values in both tables based on the join condition. If a row in either table does not have a match in the other table, that row is completely excluded from the result set. JOIN without a type keyword defaults to an INNER JOIN. Use case: get all orders that have a matching customer — orphaned orders with no customer record are excluded.

💡 Why Interviewers Ask This: The most common join type. Know that just writing JOIN (no type) defaults to an INNER JOIN in all major databases.

A LEFT JOIN returns all records from the left table, and the matched records from the right table. For left table rows that have no match in the right table, the result contains NULL values for all right table columns. Use case: get a list of all customers, including those who have made zero purchases (their order columns will be NULL).

💡 Why Interviewers Ask This: The most practical join. Interviewers confirm you know when to choose LEFT JOIN over INNER JOIN — when you need the "all from left, matched from right" pattern.

A RIGHT JOIN returns all records from the right table, and the matched records from the left table. For right table rows with no match in the left table, the result contains NULL values for the left table columns. A RIGHT JOIN is the mirror image of a LEFT JOIN — any RIGHT JOIN can be rewritten as a LEFT JOIN by swapping the table order. In practice, most developers default to LEFT JOINs and swap table order, making RIGHT JOIN rare in real code.

💡 Why Interviewers Ask This: Proves you understand table order execution. The key insight: it is exactly the inverse of LEFT JOIN.

A FULL OUTER JOIN returns all records when there is a match in either the left or the right table. Unmatched rows from both sides appear with NULL values for the columns of the table that had no match — it's the union of a LEFT JOIN and a RIGHT JOIN. Not all databases support FULL OUTER JOIN: MySQL does not support it natively. In MySQL, it is simulated by combining a LEFT JOIN and a RIGHT JOIN with UNION.

💡 Why Interviewers Ask This: Tests knowledge that MySQL requires a UNION workaround. This MySQL limitation is the expected gotcha in the answer.

A CROSS JOIN returns the Cartesian product of two tables — every row in the first table is paired with every row in the second table. If Table A has 10 rows and Table B has 10 rows, the result has 100 rows. There is no ON clause. Use cases: generating test data, creating all possible combinations (e.g., all colours × all sizes for a product). Danger: Forgetting to include the ON clause in a regular JOIN accidentally produces a CROSS JOIN, potentially returning millions of rows.

💡 Why Interviewers Ask This: The "forgotten ON clause" danger is the real reason this is asked. A CROSS JOIN on two production tables of 1M rows each generates 1 trillion rows.

A SELF JOIN is a join where a table is joined with itself. It is used to query hierarchical data or compare rows within the same table. Classic use case: finding employee-manager relationships where both the employee and their manager live in the same Employees table. Table aliases are mandatory — you must give the same table two different aliases to distinguish the two "copies": FROM Employees A JOIN Employees B ON A.ManagerID = B.ID.

💡 Why Interviewers Ask This: Advanced logic test. The employee-manager hierarchy is the canonical example. Aliases are technically required — mention them explicitly.

💡 Why Interviewers Ask This: The most frequently confused concept for junior SQL developers. Memorize: JOIN adds columns. UNION adds rows.

💡 Why Interviewers Ask This: Performance tuning awareness. Senior engineers default to UNION ALL — it's a signal that you think about query cost, not just correctness.

💡 Why Interviewers Ask This: Core data analysis knowledge. The NULL-ignoring behaviour is what they test — it affects AVG() results in ways developers don't expect.

💡 Why Interviewers Ask This: A classic trap question. Many developers wrongly assume COUNT(column) and COUNT(*) always return the same value — the NULL distinction trips them up.

💡 Why Interviewers Ask This: Tests ability to clean and format raw data. Data engineers use these constantly to prepare messy imported data for downstream consumption.

COALESCE() evaluates a comma-separated list of arguments and returns the first non-NULL value. If all arguments are NULL, it returns NULL. It is the SQL equivalent of a null-coalescing fallback. Classic use: SELECT COALESCE(Phone, Email, 'N/A') FROM Users — if Phone is NULL it tries Email; if Email is also NULL it returns the literal string 'N/A'. It can accept any number of arguments and short-circuits at the first non-NULL.

💡 Why Interviewers Ask This: The ultimate tool for handling missing data gracefully. COALESCE is far cleaner than chaining multiple CASE WHEN ... IS NULL expressions.

Window Functions perform a calculation across a set of rows that are "related" to the current row — without collapsing those rows into a single summary row (unlike aggregate functions). Each row retains its own identity in the output. Window functions use the OVER() clause, which defines the "window" of rows. The PARTITION BY sub-clause divides the window by group; ORDER BY within OVER() defines the order for ranking/running functions. Examples: RANK(), DENSE_RANK(), ROW_NUMBER(), LAG(), LEAD(), SUM() OVER().

💡 Why Interviewers Ask This: The dividing line between junior and mid-level data engineers. The OVER() clause is the mandatory signature of a window function — mention it explicitly.

💡 Why Interviewers Ask This: A guaranteed question for Data Analyst and Backend Engineer roles. The "skip vs no-skip" distinction between RANK and DENSE_RANK is the exact differentiator they test.

A Subquery (Inner Query or Nested Query) is a query embedded inside another SQL query — inside a SELECT, INSERT, UPDATE, or DELETE statement. The inner query executes first, and its result is passed to the outer query. Subqueries can appear in the WHERE clause, the FROM clause (as a derived table), or the SELECT list. Example: SELECT Name FROM Employees WHERE Salary > (SELECT AVG(Salary) FROM Employees) — finds all employees earning above average.

💡 Why Interviewers Ask This: Proves you can write multi-step logic in a single statement. The avg-salary example is the canonical illustration — know it.

A Correlated Subquery is a subquery that references one or more columns from the outer query, creating a dependency between the inner and outer queries. Because it cannot run independently, it must be executed once for every single row processed by the outer query — giving it an effective O(N²) complexity. Example: finding all employees who earn more than the average salary in their own department requires a correlated subquery that re-computes the department average for each employee row. They are inherently slow and should be replaced with a JOIN or window function whenever possible.

💡 Why Interviewers Ask This: Performance test. The O(N²) complexity and the recommendation to replace with JOINs/window functions is the senior-level insight they look for.

A CTE is a temporary, named result set defined with the WITH clause that you can reference in the subsequent SELECT, INSERT, UPDATE, or DELETE statement. Unlike subqueries, CTEs are defined once at the top and are referenced by name, making complex multi-step queries readable from top to bottom. Recursive CTEs (WITH RECURSIVE) can traverse hierarchical data like an org chart or file system. They are not physically materialized (unless the database optimizer decides to do so) and exist only for the duration of the query.

💡 Why Interviewers Ask This: Senior developers strongly prefer CTEs over deeply nested subqueries. Mentioning Recursive CTEs for hierarchical data is a senior-level signal.

A View is a virtual table defined by a stored SQL query. It has rows and columns like a real table, but it does not physically store data — every time you query a view, the underlying SQL runs to generate the result. Benefits: (1) Simplification — hide complex JOIN logic behind an easy-to-query name. (2) Security — expose only selected columns to certain users (e.g., show employee names but hide salaries). (3) Consistency — multiple queries/apps share the same query definition.

💡 Why Interviewers Ask This: Security use case (hiding sensitive columns) is the most important reason to mention. Views are the standard mechanism for column-level security in enterprise databases.

Unlike a standard View, a Materialized View physically stores the query result data on disk and is refreshed periodically (on schedule, on demand, or on data change — depending on the database). The trade-off: vastly faster reads for expensive aggregations at the cost of potentially stale data between refreshes. Use cases: pre-computing complex dashboard aggregations in data warehouses (Snowflake, BigQuery, PostgreSQL). Materialized views are the foundational building block of OLAP (analytical) systems where queries aggregate billions of rows.

💡 Why Interviewers Ask This: Advanced Data Warehousing knowledge. The stale-vs-fast trade-off and the mention of OLAP/Snowflake signals genuine experience beyond basic SQL.

An Index is an internal data structure — typically a B-Tree — that the database engine maintains to speed up data retrieval. Like a book's index, it allows the engine to jump directly to relevant rows instead of scanning every row in the table (a full table scan). Trade-offs: indexes dramatically speed up SELECT queries but slow down INSERT, UPDATE, and DELETE operations because the index structures must also be updated with every data change. They also consume additional storage.

💡 Why Interviewers Ask This: The #1 database performance tuning question. Always mention both sides: faster reads, slower writes, extra storage. Over-indexing is a real production problem.

A Clustered Index determines the physical order of data rows on disk — the table rows are sorted and stored in the same order as the index key. Because data can only be physically sorted one way, a table can have only one clustered index. In most databases, the Primary Key automatically becomes the clustered index. Clustered indexes make range queries (BETWEEN, date ranges) extremely fast because the relevant rows are physically adjacent on disk.

💡 Why Interviewers Ask This: "Only one per table" and "physically sorts the data" are the two key facts. Knowing that range queries benefit most from clustered indexes shows query optimization depth.

A Non-Clustered Index creates a separate data structure (like the index at the back of a textbook) that holds the indexed column values along with pointers (row locators) back to the actual data rows — but it does not reorder the physical data. A table can have multiple non-clustered indexes (SQL Server allows up to 999). A lookup via a non-clustered index requires an extra step — following the pointer to the actual row (a "key lookup" or "bookmark lookup") — making it slightly slower than a clustered index for the same column.

💡 Why Interviewers Ask This: Distinguishes logical lookup (non-clustered) from physical ordering (clustered). Multiple non-clustered indexes are allowed — that's the key contrast.

💡 Why Interviewers Ask This: A guaranteed interview question. Confusing these three commands is how production databases get destroyed. TRUNCATE = DDL (not DML) is the classic trap.

💡 Why Interviewers Ask This: Data integrity is a senior engineering concern. Constraints are the database's last line of defense against bad data — they enforce rules even when application code has bugs.

A Stored Procedure is a precompiled, named block of SQL code stored in the database that can be invoked with a CALL or EXEC statement. Because it is precompiled, the query plan is cached — repeated executions are faster than sending raw SQL over the network each time. Benefits: (1) Reduced network traffic — send one procedure name rather than large SQL strings. (2) Reusability — centralized business logic. (3) Security — users can execute a procedure without having direct table access.

💡 Why Interviewers Ask This: Enterprise architecture knowledge. Many legacy banking and ERP systems run almost entirely through stored procedures. Know the three benefits above.

💡 Why Interviewers Ask This: You must know when to use which. Functions = pure calculations. Procedures = stateful business logic. The "can't use a procedure in SELECT" rule is the syntax trap.

A Trigger is a special stored procedure that automatically fires in response to a specific event (INSERT, UPDATE, or DELETE) on a particular table, without being explicitly called. Triggers run either BEFORE or AFTER the triggering event. Primary use case: audit logging — automatically insert a record into a UserAuditLog table every time a user's profile is updated, capturing who changed what and when. Also used for enforcing complex business rules that CHECK constraints cannot handle.

💡 Why Interviewers Ask This: Audit trail use case is the standard expected example. Know that triggers fire automatically — they are invisible to the application code and can cause unexpected performance overhead if misused.

A Transaction is a sequence of one or more SQL operations that are executed as a single, indivisible logical unit of work. The defining rule: a transaction must execute completely (COMMIT) or not at all (ROLLBACK). If any step in the sequence fails, the entire transaction is rolled back, leaving the database in the state it was in before the transaction began. Classic example: a bank transfer — debit account A and credit account B must happen atomically. If the credit fails after the debit succeeds, you must roll back the debit to avoid losing money.

💡 Why Interviewers Ask This: The bank transfer is the canonical example — know it verbatim. Transactions are the foundation of every financial, e-commerce, and booking system.

💡 Why Interviewers Ask This: The most famous question in database history. You must define all four letters clearly. Common follow-up: "Which ACID property is sacrificed in NoSQL systems for scalability?" — answer: Consistency (BASE model).

The COMMIT command permanently saves all changes made during the current transaction to the database, ending the transaction. After a COMMIT, the changes are: (1) Durable — persisted to disk via write-ahead log, surviving crashes. (2) Visible — now visible to all other transactions and users. Once committed, the changes cannot be undone with ROLLBACK — they are permanent. If AUTOCOMMIT mode is on (MySQL default), every individual statement is automatically committed immediately after execution.

💡 Why Interviewers Ask This: Transaction lifecycle test. The AUTOCOMMIT mode detail is the advanced insight — in MySQL, you must explicitly start a transaction with BEGIN/START TRANSACTION when you want multi-statement atomicity.

The ROLLBACK command undoes all changes made during the current transaction, reverting the database to its state before the transaction began. It is the "undo" mechanism when an error occurs mid-transaction. In application code, ROLLBACK should be called in the error handler (CATCH block) when any step in a transaction fails — ensuring the database is never left in a partial state. SAVEPOINT allows partial rollbacks — you can roll back to a named intermediate point without rejecting the entire transaction.

💡 Why Interviewers Ask This: Error handling architecture test. Mentioning SAVEPOINT for partial rollbacks is a senior-level detail most candidates miss.

💡 Why Interviewers Ask This: Normalization optimizes for write-heavy (OLTP) workloads — less data redundancy means fewer places to update. Know all three normal forms in order.

Denormalization is the intentional process of adding redundancy back into a previously normalized database — merging tables and duplicating data to reduce the number of JOIN operations required for common read queries. It trades off data consistency and write performance for significantly faster reads. Use case: reporting dashboards where complex 5-table JOINs run millions of times per day. Denormalization collapses those JOINs by pre-combining the data. It is the foundation of OLAP (analytical) data warehouse design (star schema, snowflake schema).

💡 Why Interviewers Ask This: Tests real engineering trade-offs. While normalization optimizes writes (OLTP), denormalization optimizes reads (OLAP). Knowing both and when to apply each is what senior engineers are tested on.

SQL Injection is a critical security vulnerability where an attacker injects malicious SQL code through an input field to manipulate the database query. Example: a login form that builds a query as 'SELECT * FROM Users WHERE username = ' + input — an attacker entering ' OR '1'='1 makes the query always return true, bypassing authentication. Prevention: always use Parameterized Queries (Prepared Statements) — the database driver treats user input as a data value, never as executable SQL code. Additional defenses: ORMs, input validation, principle of least privilege (database user should have minimal permissions).

💡 Why Interviewers Ask This: The most critical web security question in SQL interviews. Parameterized queries are the correct, non-negotiable answer. Mentioning ORMs and least privilege shows security depth.

WITH RankedSalaries AS (
    SELECT 
        Salary,
        DENSE_RANK() OVER (ORDER BY Salary DESC) AS Rank
    FROM Employees
)
SELECT Salary 
FROM RankedSalaries 
WHERE Rank = N; -- Replace N with 2, 3, etc.

💡 Why Interviewers Ask This: The most famous SQL logic question. It tests CTEs, window functions, and sorting simultaneously. Using DENSE_RANK() instead of RANK() is what separates an advanced answer from a basic one.