For a little more context, from High Performance MySQL, 3rd Edition (2012) > This "deferred join" works because it lets the server examine as little data as po

For a little more context, from High Performance MySQL, 3rd Edition (2012) > This "deferred join" works because it lets the server examine as little data as possible in an index without accessing rows, and then, once the desired rows are found, join them against the full table to retrieve the other columns from the row. From High Performance MySQL, 4th Edition (2021) > This "deferred join" works because it lets the server examine as little data as possible in an index without accessing rows, and then, once the desired rows are found, join them against the full table to retrieve the other columns from the row. So I mean... it's not a crazy idea. Sometimes you just have to offer directly addressable pages in an application and can't get away with cursors, which are far better in certain circumstances. I agree that you'll see no benefit if you were paginating PKs in the first place, but most app developers are paginating actual records, right? This is written from the point of view of application developers. I'm sure that all the DBAs are skeptical right now, but when pages go from 30 seconds to 300 milliseconds [1] or 28 seconds to 2 seconds [2] that's kind of a win right? [1] https://twitter.com/mdavis1982/status/1482429071288066054 https://twitter.com/mdavis1982/status/1482429071288066054 [2] https://twitter.com/joecampo/status/1483550610028957701 https://twitter.com/joecampo/status/1483550610028957701