SQL

SQL (Structured Query Language) is the standard language for managing and querying data in relational database management systems (RDBMS). It is declarative — you describe what you want, not how to fetch it.

• DDL (Data Definition Language): CREATE, ALTER, DROP, TRUNCATE
• DML (Data Manipulation Language): SELECT, INSERT, UPDATE, DELETE
• DCL (Data Control Language): GRANT, REVOKE
• TCL (Transaction Control Language): COMMIT, ROLLBACK, SAVEPOINT

A database that organizes data into tables (relations) made of rows and columns, where relationships between tables are expressed via keys.

A table is a collection of related data. A row (tuple/record) is a single entry. A column (attribute/field) defines a data type and meaning for a value in each row.

SELECT * FROM employees;

Avoid SELECT * in production code — it hurts performance and breaks when the schema changes.

WHERE filters rows before grouping/aggregation. HAVING filters after GROUP BY, allowing conditions on aggregate functions.

FROM → JOIN → WHERE → GROUP BY → HAVING → SELECT → DISTINCT → ORDER BY → LIMIT/OFFSET. (Written order differs from execution order.)

NULL represents a missing or unknown value. It is not equal to 0 or an empty string, and any comparison with NULL using = yields UNKNOWN.

• DELETE removes rows (DML, can have WHERE, logged, can rollback).
• TRUNCATE removes all rows fast (DDL, resets identity, usually can't filter, minimal logging).
• DROP removes the entire table/object structure.

CHAR(n) is fixed length, padded with spaces. VARCHAR(n) is variable length, storing only the actual characters plus length info.

UPDATE employees SET salary = salary * 1.10 WHERE department_id = 3;

Always include a WHERE clause unless you intend to update every row.

A column or set of columns that uniquely identifies each row. It cannot contain NULL and must be unique. A table has at most one primary key.

A column (or columns) that references the primary key of another table, enforcing referential integrity between the two tables.

A primary or unique key made up of more than one column.

A candidate key is any column set that could uniquely identify a row (natural key). A surrogate key is an artificial identifier (e.g., auto-increment id) with no business meaning.

DISTINCT removes duplicate rows from the result set. GROUP BY groups rows to apply aggregate functions. GROUP BY without aggregates behaves similarly to DISTINCT but is more flexible.

• ANSI/PostgreSQL/Oracle: first_name || ' ' || last_name
• SQL Server: first_name + ' ' + last_name or CONCAT(...)
• MySQL: CONCAT(first_name, ' ', last_name)

= matches exact values. LIKE matches patterns using wildcards % (any sequence) and _ (single character).

A shorthand for multiple OR conditions:

SELECT * FROM employees WHERE department_id IN (1, 2, 5);

Inclusive range filter:

SELECT * FROM employees WHERE salary BETWEEN 50000 AND 80000;

• PostgreSQL/MySQL: LIMIT 10
• SQL Server: SELECT TOP 10 ... or OFFSET 0 ROWS FETCH NEXT 10 ROWS ONLY
• Oracle 12c+: FETCH FIRST 10 ROWS ONLY

=, <> (or !=), <, >, <=, >=.

AND binds tighter than OR. Use parentheses to make intent explicit:

WHERE department_id = 1 AND (salary > 50000 OR bonus > 5000)

Use COALESCE to substitute a default:

SELECT COALESCE(bonus, 0) + salary AS total_comp FROM employees;

COALESCE is ANSI standard and accepts many arguments, returning the first non-null. ISNULL (SQL Server) and NVL (Oracle) take exactly two arguments.

Returns NULL if the two arguments are equal; otherwise returns the first. Useful to avoid divide-by-zero:

SELECT total / NULLIF(count, 0) FROM stats;

Conditional logic in queries:

SELECT name,
  CASE WHEN salary > 100000 THEN 'High'
       WHEN salary > 50000  THEN 'Mid'
       ELSE 'Low' END AS band
FROM employees;

Simple CASE expr WHEN value THEN ... compares one expression to values. Searched CASE WHEN condition THEN ... evaluates arbitrary boolean conditions.

UPPER, LOWER, LENGTH=/=LEN, SUBSTRING, TRIM, LTRIM, RTRIM, REPLACE, LEFT, RIGHT, POSITION=/=CHARINDEX.

ABS, ROUND, CEIL=/=CEILING, FLOOR, MOD, POWER, SQRT, TRUNC.

• PostgreSQL: CURRENT_DATE, CURRENT_TIMESTAMP, NOW()
• MySQL: CURDATE(), NOW()
• SQL Server: GETDATE(), SYSDATETIME()
• Oracle: SYSDATE, CURRENT_TIMESTAMP

• PostgreSQL: end_date - start_date (returns days/interval)
• MySQL: DATEDIFF(end_date, start_date)
• SQL Server: DATEDIFF(DAY, start_date, end_date)

• PostgreSQL: hire_date + INTERVAL '30 days'
• MySQL: DATE_ADD(hire_date, INTERVAL 30 DAY)
• SQL Server: DATEADD(DAY, 30, hire_date)
• Oracle: hire_date + 30 or ADD_MONTHS(hire_date, 1)

You can order by output column position number (ORDER BY 2), but it's fragile — prefer column names or aliases for readability.

By default, PostgreSQL/Oracle sort NULLs last in ASC (configurable with NULLS FIRST/LAST); MySQL/SQL Server sort NULLs first in ASC. Use explicit NULLS FIRST=/=NULLS LAST where supported.

SELECT * FROM products ORDER BY id LIMIT 20 OFFSET 40;  -- page 3, 20 per page

For large offsets, prefer keyset pagination (WHERE id > :last_id).

Returns true if a subquery returns any rows. Often faster than IN for correlated checks:

SELECT * FROM customers c
WHERE EXISTS (SELECT 1 FROM orders o WHERE o.customer_id = c.id);

Compare a value against a set:

SELECT * FROM products WHERE price > ALL (SELECT price FROM clearance);
SELECT * FROM products WHERE price > ANY (SELECT price FROM clearance);

COUNT(*) counts all rows. COUNT(column) counts non-null values. COUNT(DISTINCT column) counts unique non-null values.

• PostgreSQL: STRING_AGG(name, ', ')
• MySQL: GROUP_CONCAT(name SEPARATOR ', ')
• SQL Server: STRING_AGG(name, ', ')
• Oracle: LISTAGG(name, ', ') WITHIN GROUP (ORDER BY name)

A JOIN combines rows from two or more tables based on a related column.

Returns only rows where the join condition matches in both tables:

SELECT e.name, d.name
FROM employees e
INNER JOIN departments d ON e.department_id = d.id;

Returns all rows from the left table and matching rows from the right; unmatched right-side columns are NULL.

The mirror of LEFT JOIN — all rows from the right table, matched or not.

Returns all rows from both tables, with NULL where there's no match on either side. (MySQL lacks it natively; emulate with LEFT JOIN UNION RIGHT JOIN.)

Produces the Cartesian product — every row of A combined with every row of B.

A table joined to itself, typically to compare rows or model hierarchies:

SELECT e.name AS employee, m.name AS manager
FROM employees e
LEFT JOIN employees m ON e.manager_id = m.id;

An equi-join uses = in the condition. A non-equi join uses other operators (<, >, BETWEEN), e.g., joining to a salary-band range table.

Chain JOIN clauses:

SELECT o.id, c.name, p.title
FROM orders o
JOIN customers c ON o.customer_id = c.id
JOIN order_items oi ON oi.order_id = o.id
JOIN products p ON oi.product_id = p.id;

A condition in ON of a LEFT JOIN filters which right rows match (preserving all left rows). The same condition in WHERE filters the final result and can turn the outer join into an inner join.

A shorthand when the join columns share the same name:

SELECT * FROM employees JOIN departments USING (department_id);

Automatically joins on all columns with the same name in both tables. Avoid it — it's implicit and fragile to schema changes.

Anti-join via LEFT JOIN + IS NULL:

SELECT c.* FROM customers c
LEFT JOIN orders o ON o.customer_id = c.id
WHERE o.id IS NULL;

A one-to-many or many-to-many relationship multiplies rows. Duplicate keys on the joined side fan out the result. Use DISTINCT or aggregate appropriately.

Explicit uses JOIN ... ON. Implicit lists tables in FROM with conditions in WHERE (FROM a, b WHERE a.id = b.a_id). Prefer explicit — it's clearer and avoids accidental cross joins.

Yes — a derived table:

SELECT e.name, t.total
FROM employees e
JOIN (SELECT employee_id, SUM(amount) total FROM sales GROUP BY employee_id) t
  ON t.employee_id = e.id;

A LATERAL (PostgreSQL) / CROSS APPLY / OUTER APPLY (SQL Server) lets a subquery reference columns from preceding tables in the FROM clause — useful for top-N-per-group.

Use LATERAL=/=APPLY or a window function (see Q132). Example with LATERAL:

SELECT d.name, top.name, top.salary
FROM departments d
CROSS JOIN LATERAL (
  SELECT name, salary FROM employees e
  WHERE e.department_id = d.id ORDER BY salary DESC LIMIT 3
) top;

Ensure join columns are indexed, join on the smallest necessary result set, prefer inner joins when semantics allow, and watch for unintended row multiplication. The optimizer chooses join algorithms (nested loop, hash, merge) based on statistics.

Functions that compute a single value over a set of rows: COUNT, SUM, AVG, MIN, MAX.

It collapses rows sharing the same grouping-column values into one row per group, over which aggregates are computed:

SELECT department_id, AVG(salary)
FROM employees GROUP BY department_id;

No (in standard SQL and most engines) — every selected column must be aggregated or appear in GROUP BY. MySQL historically allowed it with surprising results (ONLY_FULL_GROUP_BY now blocks it).

With HAVING:

SELECT department_id, COUNT(*) AS cnt
FROM employees GROUP BY department_id
HAVING COUNT(*) > 5;

They ignore NULLs. AVG divides by the count of non-null values, which may differ from total row count.

Creates a group for each unique combination of those column values:

SELECT department_id, job_title, COUNT(*)
FROM employees GROUP BY department_id, job_title;

Extensions to compute multiple grouping levels in one query. ROLLUP produces subtotals + grand total along a hierarchy; CUBE produces all combinations; GROUPING SETS lets you list exactly which groupings you want.

SELECT region, product, SUM(sales)
FROM orders GROUP BY ROLLUP (region, product);

Returns 1 if the column is aggregated (a subtotal/grand-total row from ROLLUP/CUBE) and 0 otherwise — useful for labeling subtotal rows.

WHERE reduces rows before aggregation (cheaper). Push conditions into WHERE whenever they don't depend on aggregates.

Use CASE inside the aggregate:

SELECT
  SUM(CASE WHEN status = 'paid' THEN amount ELSE 0 END) AS paid_total,
  COUNT(CASE WHEN status = 'open' THEN 1 END) AS open_count
FROM invoices;

PostgreSQL supports COUNT(*) FILTER (WHERE status = 'open').

MIN=/=MAX return a single aggregate value; ORDER BY ... LIMIT 1 returns the full row. To get the whole row of the max value, use ORDER BY ... LIMIT 1 or a window function.

Not directly (e.g., MAX(AVG(x)) requires a subquery or window). You compute the inner aggregate in a grouped subquery, then aggregate the result.

A query nested inside another query, used in SELECT, FROM, WHERE, or HAVING.

A non-correlated subquery runs once independently. A correlated subquery references the outer query and runs (logically) per outer row.

Returns a single value:

SELECT name, salary,
  (SELECT AVG(salary) FROM employees) AS avg_salary
FROM employees;

A subquery in the FROM clause treated as a temporary table; it must have an alias.

EXISTS can short-circuit on the first match and often performs better for correlated checks and large inner sets. IN may be better for small, static lists. Modern optimizers frequently treat them similarly. Beware NOT IN with NULLs (see Q97).

If the subquery returns any NULL, NOT IN yields no rows because the comparison becomes UNKNOWN. Prefer NOT EXISTS or filter out NULLs.

UNION combines result sets and removes duplicates (sorts/hashes — more expensive). UNION ALL keeps all rows including duplicates and is faster. Use UNION ALL unless you need dedup.

Each query must have the same number of columns with compatible data types in the same order. Column names come from the first query.

Returns rows present in both result sets. (MySQL added it in 8.0.31; older versions emulate via joins.)

Returns rows in the first set not in the second. EXCEPT (ANSI/PostgreSQL/SQL Server), MINUS (Oracle).

Yes, in row-value comparisons or in the FROM clause. In a scalar context it must return one column and at most one row.

SELECT MAX(salary) FROM employees
WHERE salary < (SELECT MAX(salary) FROM employees);

Or with window functions / OFFSET 1 LIMIT 1.

A semi-join returns rows from the left table that have a match on the right (logically EXISTS=/=IN). An anti-join returns left rows with no match (NOT EXISTS=/=NOT IN).

PRIMARY KEY, FOREIGN KEY, UNIQUE, NOT NULL, CHECK, DEFAULT.

Enforces a boolean condition on column values:

salary NUMERIC CHECK (salary >= 0)

UNIQUE ensures values are distinct but allows one (or, by ANSI rules, multiple) NULLs and you can have several per table. A primary key disallows NULLs and there's only one per table.

CASCADE, SET NULL, SET DEFAULT, RESTRICT, NO ACTION — define what happens to child rows when a referenced parent row is deleted/updated.

A column that auto-generates sequential values: SERIAL=/=GENERATED ... AS IDENTITY (PostgreSQL), AUTO_INCREMENT (MySQL), IDENTITY (SQL Server), sequences (Oracle).

The process of organizing data to reduce redundancy and improve integrity by decomposing tables and defining relationships.

• 1NF: atomic values, no repeating groups.
• 2NF: 1NF + no partial dependency (non-key columns depend on the whole composite key).
• 3NF: 2NF + no transitive dependency (non-key columns depend only on the key).

Boyce-Codd Normal Form — a stricter 3NF where every determinant is a candidate key.

Intentionally introducing redundancy to improve read performance (e.g., reporting/analytics), at the cost of update complexity and potential anomalies.

A stored named query that behaves like a virtual table:

CREATE VIEW active_employees AS
SELECT * FROM employees WHERE status = 'active';

A view whose results are physically stored and periodically refreshed — faster reads, but data can be stale. Supported in PostgreSQL/Oracle; SQL Server uses indexed views.

Sometimes — simple views over a single table without aggregation/DISTINCT/joins are often updatable. Complex views are read-only unless you define INSTEAD OF triggers.

A table that exists only for the session/transaction, useful for staging intermediate results: CREATE TEMP TABLE ... (PostgreSQL), #temp (SQL Server).

A database object that generates a sequence of unique numbers, often used for surrogate keys:

CREATE SEQUENCE order_seq START 1 INCREMENT 1;
SELECT NEXTVAL('order_seq');

Use exact numeric types (NUMERIC=/=DECIMAL), never floating point (FLOAT=/=REAL), to avoid rounding errors.

A logically single table split into physical partitions (by range, list, or hash) to improve manageability and query performance on very large datasets.

A function that computes a value across a set of rows ("window") related to the current row, without collapsing rows like GROUP BY does.

GROUP BY reduces rows to one per group. PARTITION BY keeps all rows but resets the window's calculation per partition.

• ROW_NUMBER(): unique sequential number, no ties handling.
• RANK(): ties get the same rank, leaving gaps.
• DENSE_RANK(): ties get the same rank, no gaps.

SELECT name, salary,
  ROW_NUMBER() OVER (ORDER BY salary DESC) AS rn,
  RANK()       OVER (ORDER BY salary DESC) AS rnk,
  DENSE_RANK() OVER (ORDER BY salary DESC) AS drnk
FROM employees;

Access a prior or following row's value without a self-join:

SELECT month, revenue,
  LAG(revenue) OVER (ORDER BY month) AS prev_month,
  revenue - LAG(revenue) OVER (ORDER BY month) AS delta
FROM monthly_sales;

Return the first/last/nth value in the window frame. Watch the frame clause — LAST_VALUE often needs ROWS BETWEEN UNBOUNDED PRECEDING AND UNBOUNDED FOLLOWING to behave intuitively.

The frame defines which rows around the current row are included. ROWS counts physical rows; RANGE includes rows with equal ordering values (logical range). E.g., ROWS BETWEEN 2 PRECEDING AND CURRENT ROW for a 3-row moving average.

Divides rows into N roughly equal buckets — useful for quartiles/percentiles:

SELECT name, NTILE(4) OVER (ORDER BY salary) AS quartile FROM employees;

No — windows are computed after WHERE. Wrap the query in a subquery/CTE and filter on the window column in the outer query.

A named temporary result set defined with WITH, improving readability and enabling recursion:

WITH high_earners AS (
  SELECT * FROM employees WHERE salary > 100000
)
SELECT department_id, COUNT(*) FROM high_earners GROUP BY department_id;

Functionally similar; CTEs are named, can be referenced multiple times, and support recursion. They're often clearer for complex queries. (Materialization behavior varies by engine.)

A CTE that references itself, used for hierarchies and graph traversal:

WITH RECURSIVE org AS (
  SELECT id, name, manager_id, 1 AS lvl FROM employees WHERE manager_id IS NULL
  UNION ALL
  SELECT e.id, e.name, e.manager_id, o.lvl + 1
  FROM employees e JOIN org o ON e.manager_id = o.id
)
SELECT * FROM org;

Infinite loops if the data has cycles. Many engines provide cycle detection (CYCLE clause in PostgreSQL) or you can track visited nodes; always ensure the recursion terminates.

Yes, comma-separated:

WITH a AS (...), b AS (...) SELECT * FROM a JOIN b ON ...;

Not necessarily. PostgreSQL pre-12 always materialized; 12+ may inline non-recursive CTEs. You can force with MATERIALIZED=/=NOT MATERIALIZED.

PERCENT_RANK() gives relative rank between 0 and 1. CUME_DIST() gives cumulative distribution — the fraction of rows ≤ the current row's value.

A unit of work that is executed atomically — all operations succeed (COMMIT) or none take effect (ROLLBACK).

• Atomicity: all-or-nothing.
• Consistency: transitions leave the DB in a valid state.
• Isolation: concurrent transactions don't interfere visibly.
• Durability: committed changes survive crashes.

A marker within a transaction you can roll back to without aborting the whole transaction:

SAVEPOINT sp1;
-- ...
ROLLBACK TO sp1;

From weakest to strongest: READ UNCOMMITTED, READ COMMITTED, REPEATABLE READ, SERIALIZABLE.

• Dirty read: reading uncommitted data — prevented at READ COMMITTED+.
• Non-repeatable read: a row changes between reads — prevented at REPEATABLE READ+.
• Phantom read: new rows appear in a range between reads — prevented at SERIALIZABLE.

PostgreSQL/Oracle/SQL Server default to READ COMMITTED; MySQL (InnoDB) defaults to REPEATABLE READ.

Pessimistic locks rows up front (SELECT ... FOR UPDATE). Optimistic assumes no conflict and checks a version/timestamp column at write time, retrying on mismatch.

Locks the selected rows so other transactions can't modify them until the current transaction ends — used to safely read-then-update.

Two transactions each hold a lock the other needs, blocking forever. The DB detects it and aborts one (the "victim"). Mitigate by acquiring locks in a consistent order and keeping transactions short.

Multi-Version Concurrency Control — readers see a consistent snapshot without blocking writers (and vice versa) by keeping multiple row versions. Used by PostgreSQL, Oracle, MySQL InnoDB.

A shared (read) lock allows other shared locks but blocks writes. An exclusive (write) lock blocks all other locks.

Changes remain in the transaction's scope and are invisible to others; an open transaction can hold locks and bloat undo/WAL. On disconnect, most engines roll back uncommitted work.

A mode where each statement is its own transaction, committed immediately. Most clients enable it by default; disable it to batch statements into one transaction.

Under =SERIALIZABLE=/optimistic schemes, conflicting transactions get a serialization error; the application should catch it and retry the transaction.

A data structure (usually a B-tree) that speeds up row lookup at the cost of extra storage and slower writes.

A clustered index determines the physical row order (the table is the index; one per table). A non-clustered index is a separate structure pointing to rows. (SQL Server terminology; PostgreSQL heap tables differ.)

Helps selective lookups, joins, ORDER BY, and range scans. Hurts INSERT/UPDATE/DELETE performance and consumes space. Over-indexing degrades writes.

An index on multiple columns. Order matters: an index on (a, b) supports filtering on a or a, b but not b alone (left-most prefix rule).

An index that contains all columns a query needs, so the engine answers from the index without touching the table ("index-only scan"). SQL Server uses INCLUDE columns.

Low selectivity, functions wrapping the column (WHERE UPPER(name)=...), implicit type conversions, leading wildcard LIKE '%x', stale statistics, or the optimizer estimating a scan is cheaper.

The optimizer's chosen strategy to run a query (scans, joins, order). View it with EXPLAIN=/=EXPLAIN ANALYZE (PostgreSQL/MySQL) or SET SHOWPLAN execution plan (SQL Server).

A seek navigates directly to qualifying rows (efficient, selective). A scan reads the whole index/table. Seeks are generally preferable for selective queries.

An index over a subset of rows defined by a predicate, smaller and faster for targeted queries:

CREATE INDEX idx_active ON orders (created_at) WHERE status = 'active';

An index on an expression, enabling index use for that expression:

CREATE INDEX idx_lower_email ON users (LOWER(email));

The optimizer uses table/column statistics (row counts, value distribution) to estimate costs. Stale stats lead to bad plans; refresh with ANALYZE=/=UPDATE STATISTICS.

Missing indexes, SELECT *, non-sargable predicates, large unfiltered scans, N+1 query patterns, bad join order, parameter sniffing, lock contention, and insufficient memory causing spills to disk.

Search ARGument ABLE — a predicate that can use an index (e.g., col = :v or col > :v). Wrapping the column in a function or doing arithmetic on it usually makes it non-sargable.

Use keyset (seek) pagination instead of large OFFSET:

SELECT * FROM orders WHERE id > :last_seen_id ORDER BY id LIMIT 20;

Over time, page splits and deletes leave indexes fragmented, hurting scans. Rebuild or reorganize indexes (REINDEX, ALTER INDEX ... REBUILD) and tune fill factor.

Insert-or-update on conflict:

-- PostgreSQL
INSERT INTO inventory (sku, qty) VALUES ('A1', 10)
ON CONFLICT (sku) DO UPDATE SET qty = inventory.qty + EXCLUDED.qty;

-- MySQL
INSERT INTO inventory (sku, qty) VALUES ('A1', 10)
ON DUPLICATE KEY UPDATE qty = qty + VALUES(qty);

A single statement to insert/update/delete a target based on a source — standard SQL, supported by SQL Server/Oracle/PostgreSQL 15+:

MERGE INTO target t USING source s ON t.id = s.id
WHEN MATCHED THEN UPDATE SET t.val = s.val
WHEN NOT MATCHED THEN INSERT (id, val) VALUES (s.id, s.val);

Conditional aggregation or PIVOT (SQL Server/Oracle):

SELECT
  SUM(CASE WHEN quarter='Q1' THEN sales END) AS q1,
  SUM(CASE WHEN quarter='Q2' THEN sales END) AS q2
FROM revenue GROUP BY region;

UNPIVOT (SQL Server/Oracle) or UNION ALL / CROSS JOIN LATERAL (VALUES ...) in PostgreSQL.

A precompiled set of SQL statements stored in the database, callable by name, supporting parameters and control flow — useful for encapsulating business logic and reducing round-trips.

Functions return a value and can be used in queries (usually no side effects); procedures perform actions (DML, transactions) and are invoked with CALL=/=EXEC, often without returning a usable value in a SELECT.

Code that automatically executes in response to INSERT=/=UPDATE=/=DELETE events on a table — used for auditing, validation, or maintaining derived data. Use sparingly; they hide logic and can hurt performance.

Modern engines have JSON types: PostgreSQL jsonb, MySQL JSON, SQL Server JSON functions.

SELECT data->>'name' FROM events WHERE data->>'type' = 'click';  -- PostgreSQL

Index jsonb with GIN indexes for containment queries.

Options: adjacency list (parent_id + recursive CTE), nested sets, materialized path, or closure tables — each trades read vs. write complexity.

Time-based windows, e.g., a 7-day rolling sum based on dates rather than row counts:

SUM(amount) OVER (ORDER BY ts RANGE BETWEEN INTERVAL '7 days' PRECEDING AND CURRENT ROW)

The "gaps and islands" pattern uses ROW_NUMBER() differences to group consecutive runs:

SELECT MIN(d), MAX(d) FROM (
  SELECT d, d - (ROW_NUMBER() OVER (ORDER BY d)) * INTERVAL '1 day' AS grp
  FROM activity
) t GROUP BY grp;

Logical independence: schema (logical) changes don't break applications (via views). Physical independence: storage/index changes don't affect the logical schema.

Batch it (e.g., DELETE ... WHERE id IN (SELECT id ... LIMIT 10000) in a loop) to limit lock duration and transaction log growth, commit between batches, and run during low-traffic windows.

SELECT *, implicit joins, N+1 queries, scalar functions in WHERE on indexed columns, storing comma-separated lists instead of relations (EAV/jaywalking), missing foreign keys, and overusing triggers/cursors.

Use parameterized queries / prepared statements — never concatenate user input into SQL. Apply least-privilege DB accounts, validate input, and use ORMs/query builders that parameterize by default.