[update] And thanks to Gus and Al Davidson, some sample SQL for avoiding the problem - check out the comments!
Lets say you want to display a list of categories in an e-commerce store, but you’d also like to display how many products are in each. A naive solution might look something like:
<cfquery name="GetProductCount" datasource="mydatasource">
SELECT Count(ProductID) as ProductCount
WHERE ProductCategoryID = #CategoryID#
So, how many queries are we going to be running? Well, even if there are no categories we will be running 1 query (to get the category list). If there is 1 category we’d run 1 category list query and 1 product count query. If 2 categories we’d run 1 category list query and 2 product count queries (one per category). In general terms we'll always run 1 category query and n-product count queries for an n-category situation, hence this is an “n+1 query” solution (for example, 50 categories, 51 queries).
The problem with n+1 query situations is that typically for simple web applications, database queries are one of the biggest bottlenecks in terms of performance, and running a lot of them sequentially is usually a bad thing. Lets say an average query took 50ms and we had 49 categories. That would suggest 2500ms (2.5 seconds) just to process the queries for a single page!
While you don’t want to get involved in premature optimization, be aware whenever you see an n+1 query situation as it may well be something you'll have to replace with a more sophisticated query if performance of that part of the application becomes a problem.