285

My iPhone application connects to my PHP web service to retrieve data from a MySQL database, a request can return up to 500 results.

What is the best way to implement paging and retrieve 20 items at a time?

Let's say I receive the first 20 entries from my database, how can I now request the next 20 entries?

Skully
  • 2,882
  • 3
  • 20
  • 31
aryaxt
  • 76,198
  • 92
  • 293
  • 442

9 Answers9

416

From the MySQL documentation:

The LIMIT clause can be used to constrain the number of rows returned by the SELECT statement. LIMIT takes one or two numeric arguments, which must both be nonnegative integer constants (except when using prepared statements).

With two arguments, the first argument specifies the offset of the first row to return, and the second specifies the maximum number of rows to return. The offset of the initial row is 0 (not 1):

SELECT * FROM tbl LIMIT 5,10;  # Retrieve rows 6-15

To retrieve all rows from a certain offset up to the end of the result set, you can use some large number for the second parameter. This statement retrieves all rows from the 96th row to the last:

SELECT * FROM tbl LIMIT 95,18446744073709551615;

With one argument, the value specifies the number of rows to return from the beginning of the result set:

SELECT * FROM tbl LIMIT 5;     # Retrieve first 5 rows

In other words, LIMIT row_count is equivalent to LIMIT 0, row_count.

Community
  • 1
  • 1
Faisal Feroz
  • 12,458
  • 4
  • 40
  • 51
  • 155
    When using LIMIT for paging you should also specify an ORDER BY. – Mark Byers Sep 26 '10 at 18:42
  • 19
    @shylent: Nothing wrong with quoting the documentation, but I agree that he should have mentioned that he was copying the docs and provided a link to the original source. Also I'm surprised that the documentation would include examples of using LIMIT without an ORDER BY... that seems like a bad practice to be encouraging. Without an ORDER BY there's no guarantee that the order will be the same between calls. – Mark Byers Sep 26 '10 at 18:59
  • 18
    anyway, when paginating large resultsets (and that's what pagination is for - break up large resultsets into smaller chunks, right?), you should keep in mind that if you do a `limit X, Y`, what essentially happens is that X+Y rows are retrieved and then X rows from the beginning are dropped and whatever left is returned. To reiterate: `limit X, Y` results in scan of X+Y rows. – shylent Sep 26 '10 at 19:01
  • 9
    I don't like your LIMIT 95, 18446744073709551615 idea.. take a look at `OFFSET` ;-) – CharlesLeaf Sep 26 '10 at 19:21
  • 2
    It's from the MySQL documentation. – thomasrutter Aug 02 '12 at 07:57
  • how can we know if there are any more rows after first few before hand? – pinkpanther Jan 28 '14 at 10:52
  • If you made it this far down this link might help you http://www.xarg.org/2011/10/optimized-pagination-using-mysql/ – Jane Panda Apr 18 '14 at 04:20
  • 1
    The main problem is with the OFFSET, not with the LIMIT. There are ways to avoid it: https://stackoverflow.com/a/32360867/2859065 – Luchostein Sep 02 '15 at 18:47
  • @CharlesLeaf You can't have an OFFSET without a limit, that's why that big number is there. – mpen Aug 09 '16 at 23:43
  • Q, How can we start from the end of the table?? Since i want first last 10 rows and then on click on PREVIOUS i want 10 more rows from end of table?? – mukesh patel Sep 30 '16 at 06:40
  • 5
    This is not efficient when working with large data. Check http://codular.com/implementing-pagination for mutiple ways whicg are suitable for specific scenerio. – Amit Oct 12 '17 at 14:32
  • Make sure that your ORDER BY clause defines a strict order. For example on a table with people and their age you should use `ORDER BY age ASC, id ASC` where `id` is your primary key instead of just `ORDER BY age ASC`. This ensures that people with the same age are always sorted the same way. – jlh Nov 05 '17 at 12:19
  • The question asked for the "best way". `OFFSET` gives you the _easiest_ way. The other answers give you the _most efficient_ answer. – Rick James Oct 04 '18 at 19:45
  • 1
    Downvoted due to performance concerns. https://dzone.com/articles/why-most-programmers-get-pagination-wrong – gdbj Mar 11 '19 at 15:03
167

For 500 records efficiency is probably not an issue, but if you have millions of records then it can be advantageous to use a WHERE clause to select the next page:

SELECT *
FROM yourtable
WHERE id > 234374
ORDER BY id
LIMIT 20

The "234374" here is the id of the last record from the prevous page you viewed.

This will enable an index on id to be used to find the first record. If you use LIMIT offset, 20 you could find that it gets slower and slower as you page towards the end. As I said, it probably won't matter if you have only 200 records, but it can make a difference with larger result sets.

Another advantage of this approach is that if the data changes between the calls you won't miss records or get a repeated record. This is because adding or removing a row means that the offset of all the rows after it changes. In your case it's probably not important - I guess your pool of adverts doesn't change too often and anyway no-one would notice if they get the same ad twice in a row - but if you're looking for the "best way" then this is another thing to keep in mind when choosing which approach to use.

If you do wish to use LIMIT with an offset (and this is necessary if a user navigates directly to page 10000 instead of paging through pages one by one) then you could read this article about late row lookups to improve performance of LIMIT with a large offset.

Mark Byers
  • 811,555
  • 193
  • 1,581
  • 1,452
  • 1
    This is more like it :P While I absolutely disapprove of the implication, that 'newer' ids are always larger, than 'older' ones, *most of the time* this will indeed be the case and so, I think, this is 'good enough'. Anyway, yes, as you demonstrated, proper pagination (without severe performance degradation on large resultsets) is not particularly trivial and writing `limit 1000000, 10` and hoping that it will work won't get you anywhere. – shylent Sep 26 '10 at 19:08
  • 1
    the late lookup link is very usefull – pvgoddijn May 04 '15 at 15:45
  • 1
    This pagination works backwards if you just use "DESC" for id ordering. I like it! – Dennis Heiden Nov 24 '16 at 13:42
  • 2
    but how often do people want to order by ID or, by insinuation, by "date created" in the real world? – RichieHH May 06 '17 at 07:42
  • good post, but `area=width*height` so it's not just the quantity of records that might matter, but the size of each record is also a factor when storing results in memory – nothingisnecessary Jun 07 '17 at 19:14
  • This wont work with UUID tho, right? i know this is an old question, just trying to keep it updated. – Zorkind Jul 17 '18 at 18:52
  • Keyset pagination FTW. All our apps slowest queries use OFFSET, which we are now replacing with Keyset paging. – gdbj Mar 11 '19 at 15:05
  • I would argue that this is the best approach for pagination in relational databases, considering it's restrictions. – Marco Pelegrini May 06 '19 at 22:48
  • 4
    This only works if you want to order by a unique property, like the primary key. As soon as you order by something like say, date, this won't work at all. – nickdnk Jul 20 '19 at 01:47
  • I have to agree that this is the last way I would ever implement pagination since I never order by ID field – RickInWestPalmBeach Sep 15 '20 at 12:55
  • @RickInWestPalmBeach You don't "have to" order by ID. This method can be applied on any unique key (e.g. timestamp), even multiple key (e.g. timestamp + something if two transactions may come at the same time with a very small probability). The cases of multiple key are a little more complex (e.g. the `WHERE` condition may become something like `WHERE timestamp <= XXX AND (another_field < ooo OR timestamp < XXX)` to avoid the problem of the same timestamp transactions), but the concept is still the same. – Ddavid Aug 25 '21 at 02:18
100

Define OFFSET for the query. For example

page 1 - (records 01-10): offset = 0, limit=10;

page 2 - (records 11-20) offset = 10, limit =10;

and use the following query :

SELECT column FROM table LIMIT {someLimit} OFFSET {someOffset};

example for page 2:

SELECT column FROM table
LIMIT 10 OFFSET 10;
Danton Heuer
  • 397
  • 4
  • 11
Prabodh Hend
  • 1,321
  • 1
  • 12
  • 15
  • 1
    Don't you mean offset = 10 for page-2 ? – Jenna Maiz Feb 11 '17 at 23:14
  • I did limit 10 offset 0 to get the first 10 results, then limit 10 offset 1 to get the second.. etc. I like this, but how can you tell the total amount of pages or offsets? – themhz Oct 02 '21 at 16:53
38

There's literature about it:

The main problem happens with the usage of large OFFSETs. They avoid using OFFSET with a variety of techniques, ranging from id range selections in the WHERE clause, to some kind of caching or pre-computing pages.

There are suggested solutions at Use the INDEX, Luke:

Luchostein
  • 2,314
  • 20
  • 24
  • 1
    getiing max id for each paging query of complex queries would result in non practical , non producation usage does rank , row number and between clause type of paging helps in performace ! – Rizwan Patel Jan 09 '17 at 12:12
  • That strategy is taken into consideration and properly evaluated in the provided links. It's not that simple at all. – Luchostein Jan 09 '17 at 13:43
  • the provided link only seems to fulfil base pivot uni-pivot , cross apply , multi CTE or derived table mechanics ? again i stand by my case with rewriting queries on such magnitude again for getting maxid is architectural overkill ! and then again permutation and combination for n" number of column with sort orders ! – Rizwan Patel Jan 09 '17 at 16:30
  • 1
    Am I misunderstanding that "Pagination done the right way" link, or is it simply impractical in any query that involves filtering. – contactmatt Jun 06 '18 at 21:48
  • 1
    @contactmatt I share your aprehension. In the end, it seems there's no way to implement efficiently the full requirement, but relaxed variations around the original. – Luchostein Jun 08 '18 at 18:36
13

This tutorial shows a great way to do pagination. Efficient Pagination Using MySQL

In short, avoid to use OFFSET or large LIMIT

Bao Le
  • 16,643
  • 9
  • 65
  • 68
10

you can also do

SELECT SQL_CALC_FOUND_ROWS * FROM tbl limit 0, 20

The row count of the select statement (without the limit) is captured in the same select statement so that you don't need to query the table size again. You get the row count using SELECT FOUND_ROWS();

HoldOffHunger
  • 18,769
  • 10
  • 104
  • 133
surajz
  • 3,471
  • 3
  • 32
  • 38
  • 1
    This is particularly inefficient. The `*` results in more columns than necessary being fetched, and the `SQL_CALC_FOUND_ROWS` results in those columns being read from *all* rows in the table, even though they are not included in the result. It would be a lot more efficient to calculate the number of rows in a separate query which doesn't read all those columns. Then your main query can stop after reading 20 rows. – thomasrutter Aug 02 '12 at 07:59
  • Are you sure? I timed the query against a large table SQL_CALC_FOUND_ROWS and another query not using. I saw no time difference. Any ways it is faster than doing 2 queries . 1 - select * from atable limit 0 20, and then select count(*) from atable. – surajz Aug 02 '12 at 16:11
  • 1
    Yes I'm sure - [here's more info](http://www.mysqlperformanceblog.com/2007/08/28/to-sql_calc_found_rows-or-not-to-sql_calc_found_rows/). In all cases when you are using an index to filter rows, SQL_CALC_FOUND_ROWS is significantly slower than doing 2 separate queries. On the rare occasion you are not using an index, or (as in this simplified example) you have no WHERE clause and it's a MYISAM table, it makes little difference (it's around the same speed). – thomasrutter Aug 03 '12 at 02:31
  • Also here's a [discussion about it on Stackoverflow](http://stackoverflow.com/a/188682/53212) – thomasrutter Aug 03 '12 at 02:33
7

Query 1: SELECT * FROM yourtable WHERE id > 0 ORDER BY id LIMIT 500

Query 2: SELECT * FROM tbl LIMIT 0,500;

Query 1 run faster with small or medium records, if number of records equal 5,000 or higher, the result are similar.

Result for 500 records:

Query1 take 9.9999904632568 milliseconds

Query2 take 19.999980926514 milliseconds

Result for 8,000 records:

Query1 take 129.99987602234 milliseconds

Query2 take 160.00008583069 milliseconds

Huy
  • 91
  • 1
  • 6
  • You need to put an index on `id`. – Maarten May 18 '15 at 15:00
  • 8
    How is `id > 0` useful? – Michel Jung Nov 16 '15 at 09:40
  • 1
    Like Maarten said, those two queries appear fundamentally the same, and probably break down into the same, machine-level commands either way. You must have an indexing problem or a really old version of MySQL. – HoldOffHunger Aug 22 '16 at 13:42
  • thanks , as in i didnt saw your answer , i just needed to see the order in which where , order and limit comes – Shreyan Mehta Jul 12 '19 at 11:31
  • 1
    wrong example has been used. with `offset`(the first argument to limit is offset), you are still selecting all the data to the limit, then discarding that amount of the offset, then returning the section which is between `offset` and `limit`. with `where` clause on the other hand, you are setting a kind of a start point for the query and query `ONLY` that specific part. – senaps Sep 07 '19 at 11:59
1

Here's how I'm solving this problem using node.js and a MySQL database. First, lets declare our variables!

    const 
        Key = payload.Key,
        NumberToShowPerPage = payload.NumberToShowPerPage,
        Offset = payload.PageNumber * NumberToShowPerPage;

NumberToShowPerPage is obvious, but the offset is the page number.

Now the SQL query...

    pool.query("SELECT * FROM TableName WHERE Key = ? ORDER BY CreatedDate DESC LIMIT ? OFFSET ?", [Key, NumberToShowPerPage, Offset], (err, rows, fields) => {}));

I'll break this down a bit.

  1. Pool, is a pool of MySQL connections. It comes from mysql node package module. You can create a connection pool using mysql.createPool.
  2. The ?s are replaced by the variables in the array [PageKey, NumberToShow, Offset] in sequential order. This is done to prevent SQL injection.
  3. See at the end were the () => {} is? That's an arrow function. Whatever you want to do with the data, put that logic between the braces.
  4. Key = ? is something I'm using to select a certain foreign key. You would likely remove that if you don't use foreign key constraints.

Hope this helps.

Sean Patnode
  • 121
  • 1
  • 4
0

If you are wanting to do this in a stored procedure you can try this

SELECT * FROM tbl limit 0, 20.

Unfortunately using formulas doesn't work so you can you execute a prepared statement or just give the begin and end values to the procedure.

buddemat
  • 4,552
  • 14
  • 29
  • 49