All those records from customers that have no orders:
SELECT *
FROM Customers c
LEFT JOIN Orders o ON o.CustomerId = c.CustomerId
WHERE o.CustomerId IS NULL
Not really sure I would represent your customers orders relationship like that vent diagram because it implies to me that there can be orders that have no customers but I'll overlook that
When we left join we get all the customers plus any orders they have made. Customers that have made no orders have a null in the related o.CustomerId and that is what we look for in the where clause
It is most reliable to use (one of) the column(s) specified in the join condition when doing this test. Any other column from orders might be null for other reasons (product type not known, for example) unless it is specified as NOT NULL in the table definition. To save looking this up we rely on the fact that the only way o.CustomerId can be null in this particular query (where it is mentioned in the join) is if there is no matching order row for that customer
You could also use either these:
SELECT *
FROM Customers c
WHERE c.CustomerId NOT IN (SELECT CustomerId FROM orders)
SELECT *
FROM Customers c
WHERE NOT EXISTS (SELECT null FROM orders o WHERE o.CustomerID = c.CustomerID)
In most high end database systems these will all be implemented the same under the hood; the query compiler will recognise the job they're trying to do and carry them out in the same way. There's a risk that the NOT IN will perform poorly in some databases, particularly older or more naively written ones, and it's perhaps a reasonable rule of thumb to follow that "do not use IN for lists longer than you would happily type in manually". The EXISTS version is called a coordinated subquery and is often a fairly succinct and high performing way of doing things like this- for a long time databases have had specific optimisations for EXISTS that they formerly might not have had for a JOIN based route but that's again something that has largely gone away nowadays. Seeing someone exhibit a preference for EXISTS may indicate they've been using SQL a loooong time, as it was frequently the best performing way of answering this type of query in ancient databases
Of all 3 I find the join method clearest to read and understand - coordinated subqueries always require a bit more mental effort to see how they hook into the bigger picture because they refer to columns that aren't part of their local scope. It's also possible to make a mistake with a coordinated subquery more easily than the other forms, and particularly with the IN, by typoing a column from the outer query into the inner query, changing the results it emits.
Use whatever works for you; being able to read and understand all these forms will help you when you read other people's code