You change one line in your SQL, swap LEFT JOIN for INNER JOIN, and suddenly half your rows are gone. Or worse, you didn't touch anything and the results are still wrong. If that's happened to you, don't worry, it's way more common than people admit. Most devs who've worked with SQL in production have a story like this somewhere, and honestly the problem is rarely a lack of knowledge about what each join "does." It's more that nobody actually stopped to think about what happens when the two tables meet. I'm not going to repeat the usual tutorial with a generic users and orders table and no context at all. I'd rather explain this in a way that actually sticks, show where most people trip up, and by the end you should be able to decide which join to use on the spot without memorizing any rule. Forget the textbook definition for a second. Picture two tables as two groups of people at a party. INNER JOIN is like the line at the door: only people on both guest lists get in. If the name doesn't match on both sides, that person stays out, plain and simple. It's the pure intersection of the two sets. LEFT JOIN thinks differently. It starts from the left table and says: everyone here gets in, whether or not they have a match on the other side. When there's no matching row on the right, SQL doesn't drop the row, it just fills the right-side columns with NULL and moves on. Basically it's "show me everyone from A, and when there's info from B I'll show it, when there isn't I'll leave it blank." That difference in mindset, between "only people who show up on both sides" and "everyone on the left, filled in when possible," is pretty much all you need to remember. Let's make this a bit more concrete. Say you've got a customers table and an orders table. With INNER JOIN between them, you only get customers who've placed at least one order, anyone who never bought anything disappears from the results because there's no matching row in orders. Now switch to LEFT JOIN starting from customers. The result changes in nature: you see everyone, including people who never bought anything, and for those the order columns come back as NULL. That's exactly the behavior you need when you're trying to answer something like "which registered customers have never placed an order," a question INNER JOIN literally can't answer, since anyone without an order was already dropped before you even applied a filter. This is usually the point where it clicks. Which join you pick isn't a style choice, it decides which questions your query is even capable of answering. And here's the most common, most annoying bug in this whole topic, one you've probably run into without realizing it. You write a LEFT JOIN correctly, thinking it'll bring back all customers, including the ones with no orders. Then you add a condition in the WHERE clause filtering on some column from the right table, say orders above a certain amount. For a customer with no order at all, that column comes back NULL, and NULL never satisfies a "greater than" comparison. So those rows quietly get filtered out by the WHERE clause, and your LEFT JOIN ends up behaving exactly like an INNER JOIN in disguise, no error, no warning, just a wrong result nobody notices until the numbers stop matching in someone's report. The fix is usually to move that condition into the join's own ON clause instead of leaving it in the WHERE, or to handle the NULL case explicitly. Small syntax detail, pretty big consequence for the result. And it's the kind of bug that survives in production for months because the query "looks" correct. There's also this idea floating around that LEFT JOIN is always slower than INNER JOIN, like it's some law of nature. In practice it depends on the execution plan, the indexes involved, the data volume, there's no blanket guarantee either way. Honestly, in most cases I've seen, that difference is irrelevant next to the impact of a missing index or a badly written ON clause. Before ruling out a LEFT JOIN over performance fears, it's worth actually running an EXPLAIN and looking at the real plan instead of trusting a rule that gets repeated without any source behind it. At the end of the day it comes down to one question: do you need to see rows from the left side even when there's no match on the other side? If yes, LEFT JOIN. If you only want cases with a guaranteed match on both sides, INNER JOIN. It's not a rule to memorize, it's a question to ask about the problem you're actually solving, and once that becomes a habit the right choice feels pretty obvious before you even write the query. Curious what's the strangest bug this kind of mix-up has caused you. If you've ever burned time figuring out why a query "should" return every row and didn't, or found out way too late that a WHERE clause was quietly undoing your LEFT JOIN, drop it below.