Editing SQL (section)

== <span style="color: #FFFFFF;">Analyzing</span> ==
'''Joins''' are the most misunderstood feature:

* '''INNER JOIN''' � returns only rows with a match in both tables. Rows with no match are silently dropped.
* '''LEFT JOIN''' � returns all rows from the left table; unmatched right-side columns are NULL.
* '''RIGHT JOIN''' � the mirror of LEFT JOIN (rarely used; usually rewritten as a LEFT JOIN).
* '''FULL OUTER JOIN''' � returns all rows from both tables, NULLs where there is no match.
* '''CROSS JOIN''' � every row from the left combined with every row from the right (Cartesian product); rarely intentional.

'''NULL behavior''' is a frequent source of bugs. NULL is not equal to anything, including itself � <code>NULL = NULL</code> evaluates to NULL (unknown), not TRUE. Filtering with <code>WHERE col != 'x'</code> silently excludes NULL rows. Use <code>IS NULL</code> / <code>IS NOT NULL</code> explicitly.

'''Index trade-offs''':
* An index on a column makes reads faster (O(log n) vs O(n) scan) but slows writes because the index must be updated on every INSERT/UPDATE/DELETE.
* Indexes are most effective on high-cardinality columns (many distinct values) used frequently in WHERE or JOIN conditions.
* A composite index on (a, b) helps queries filtering on a alone or on a and b together, but not on b alone.

'''N+1 query problem''': fetching a list of N records and then issuing one query per record to get related data results in N+1 round trips. Fix it with a JOIN or a single IN (...) query instead.
</div>

<div style="background-color: #483D8B; color: #FFFFFF; padding: 20px; border-radius: 8px; margin-bottom: 15px;">