I'm wondering if there is a method to get the amount of is a result of a MySQL query, and simultaneously limit the outcomes.

The way in which pagination works (when i comprehend it), first I actually do something similar to

query = Choose COUNT(*) FROM `table` WHERE `some_condition`

Once I obtain the num_rows(query), I've the amount of results. However to really limit my results, I must perform a second query like:

query2 = Choose COUNT(*) FROM `table` WHERE `some_condition` LIMIT , 10

My question: Can there be anyway to both retrieve the entire quantity of results that might be given, AND limit the outcomes came back in one query? Or anymore efficient method of carrying this out. Thanks!

No, that's the number of programs that are looking to paginate need to do it. It's reliable and bullet-proof, although it can make the query two times. However, you can cache the count for any couple of seconds which will be very convenient.

Another way is by using SQL_CALC_FOUND_ROWS clause after which call Choose FOUND_ROWS(). aside from the very fact you need to place the FOUND_ROWS() call later on, there's an issue with this: There's a bug in MySQL this tickles that affects ORDER BY queries which makes it much reduced on large tables compared to naive approach of two queries.

I never do two queries.

Simply return yet another row than is required, only display 10 around the page, and when you will find a lot more than are displayed, display a "Next" button.

Choose COUNT(*) FROM table WHERE some_condition LIMIT , 11

// iterate through and display 10 rows.

// if there have been 11 rows, display a "Next" button.

Your query should return within an order on most relevant first. Odds are, many people aren't likely to worry about likely to page 236 from 412.

Whenever you perform a search, as well as your results aren't on page one, you likely visit page two, not nine.

In many situations it's considerably faster and fewer resource intensive to get it done in 2 separate queries than to get it done in a single, despite the fact that that appears counter-intuitive.

If you are using SQL_CALC_FOUND_ROWS, then for big tables it can make your query much reduced, considerably reduced even than performing two queries, the very first having a COUNT(*) and also the second having a LIMIT. The reason behind this really is that SQL_CALC_FOUND_ROWS causes the LIMIT clause to become applied after fetching the rows rather than before, therefore it brings the whole row for those possible results before using the limits. This cannot be satisfied by a catalog since it really brings the information.

For the 2 queries approach, the first only fetching COUNT(*) and never really fetching and actual data, this is often satisfied a lot more rapidly since it usually can use indexes and does not need to fetch the particular row data for each row it appears at. Then, the 2nd query only needs to check out the very first $offset+$limit rows after which return.

This publish in the MySQL performance blog describes this:

http://world wide web.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/

For additional info on optimising pagination, check this publish and this publish.

Another method of staying away from double-querying would be to fetch all of the rows for that current page utilizing a LIMIT clause first, then only perform a second COUNT(*) query when the most of rows were retrieved.

In lots of programs, probably the most likely outcome is going to be that all the results fit on a single page, and needing to do pagination may be the exception as opposed to the norm. In these instances, the very first query won't retrieve the utmost quantity of results.

For instance, solutions on the stackoverflow question rarely spill onto another page. Comments with an answer rarely spill within the limit of 5 approximately needed to exhibit all of them.

So during these programs you can just just perform a query having a LIMIT first, after which as lengthy as to limit isn't arrived at, you realize exactly the number of rows you will find with no need to perform a second COUNT(*) query - that ought to cover nearly all situations.