# Query Advisor Results

**URL:** <https://forums.percona.com/t/query-advisor-results/2400>\
**Category:** Other Tools\
**Created:** [February 17, 2012, 11:55am UTC](https://forums.percona.com/t/query-advisor-results/2400 "2012-02-17T11:55:53Z")\
**Posts on this page:** 3\
**Page:** 1

<div class="post-metadata">

**Author:** ![gms8994](https://avatars.discourse-cdn.com/v4/letter/g/e9bcb4/32.png) [@gms8994](https://forums.percona.com/u/gms8994)\
**Post date:** [February 17, 2012, 11:55am UTC](https://forums.percona.com/t/query-advisor-results/2400/1 "2012-02-17T11:55:53Z")

</div>

Per Baron, I’m pasting this here:

[URL][http://tools.percona.com/query/PLUQcFBa/advice[/URL]](http://tools.percona.com/query/PLUQcFBa/advice%5B/URL%5D)

specifically, I can’t seem to find any information on CLA.003 (Paginating a result set with LIMIT and OFFSET is O(n^2) complexity, and will cause performance problems as the data grows larger. Pagination techniques such as bookmarked scans are much more efficient.) and “bookmarked scans”.

---

<div class="post-metadata">

**Author:** ![xaprb](https://avatars.discourse-cdn.com/v4/letter/x/49beb7/32.png) [@xaprb](https://forums.percona.com/u/xaprb)\
**Post date:** [February 17, 2012, 12:11pm UTC](https://forums.percona.com/t/query-advisor-results/2400/2 "2012-02-17T12:11:40Z")

</div>

The reason it’s warning about CLA.003 is this:

LIMIT 20 OFFSET 7620

This means that the query will actually generate 7620 + 20 rows, and then throw away the first 7620. That is, 99.74% of the work it’s doing is wasted.

A bookmarked scan works like this: select the first 21 results, display 20, and remember the 21st result. Next time, use a greater-than or less-than with the 21st result as the starting point and a LIMIT 21 again. To generate the third page, start from the 41st row, and so on. This way the query is only generating 20 rows at a time.

However, this won’t help in your case, because you have a GROUP BY, and some ORDER BY problems that will prevent early materialization. This query will always generate a temporary table with ALL the rows, sort them, then scan them and retrieve the desired rows.

This is a very common type of problem in applications that show paginated displays. There are a variety of ways to solve it; I’d begin with the slides for “Efficient Pagination Using MySQL” from our 2009 conference, listed here: [URL][http://www.percona.com/live/santa-clara-2009/[/URL]](http://www.percona.com/live/santa-clara-2009/%5B/URL%5D)

---

<div class="post-metadata">

**Author:** ![gms8994](https://avatars.discourse-cdn.com/v4/letter/g/e9bcb4/32.png) [@gms8994](https://forums.percona.com/u/gms8994)\
**Post date:** [February 17, 2012, 1:40pm UTC](https://forums.percona.com/t/query-advisor-results/2400/3 "2012-02-17T13:40:40Z")

</div>

Can I suggest linking to that slide deck from that warning? Googling for “bookmarked scans” doesn’t work very well…
