These four all deal with associations, and they're easy to mix up. The way I keep them straight is to ask two questions about each: what SQL does it run, and does it actually pull the associated records into memory? Once you can answer both, picking the right one is straightforward.

joins

joins builds a SQL join but does not load anything into memory. User.joins(:posts).where(posts: { published: true }) filters users by their posts cheaply. But if you then call user.posts in Ruby, you get a fresh query for every user, which is the N+1 you were trying to avoid, because the posts were never loaded. Use joins to filter and sort, not to display.

preload

preload always runs separate queries, one for the users and one for their posts, then stitches them together in memory. There is no join, so you can't reference the posts table in a where. Try it and Rails will complain.

eager_load

eager_load forces a single LEFT OUTER JOIN and builds the association out of the joined rows. Unlike preload, it still works when you filter on the joined table, because the join is right there in the query.

includes

includes is the one I reach for most. You're telling Rails what you want ("load these associations, don't N+1 me") and letting it choose the strategy. By default it preloads with separate queries. The moment you reference the associated table in a where or order, it switches to eager_load and runs the join instead. You usually don't have to think about which.

Putting it to work

Two quick cases to make it stick.

To list users along with their posts, use User.includes(:posts). You're displaying the association, so separate queries are fine and you've killed the N+1.

To find only the users who have published posts, use User.joins(:posts).where(posts: { published: true }). You're filtering by the association and you never need the post objects in memory, so there's no reason to load them. If you want to filter and then display those posts, use includes together with references, or just use eager_load.