Pagination - many rows + offset = slow performance
Hey guys.
I have a table with 1 milion rows which i want to paginate. The pagination works fine until you reach around 1000+ pages then it´s slowing down and around 10000 page it´s not able to even generate the view and the app will crash down or it takes around 30 seconds to load because of the large offset.
The only problem here is the offset included in the query. The greater offset is the more slower app is. How do you deal with pagination which have ten thousand of pages ex. 55 thousands?
I have a query where the offset is 179 thousand and I have to wait 30 seconds to load the page.
Sounds more like a database problem than a code problem. Is the query slow if you execute it natively as well? Are the columns you are ordering by indexed?
When you get that much data a standard MySQL will slow down. Pagination by default gets a * count which is slower the counting just one column. With offsets same thing.
Basically when working with big data you have to be sure the database is cfg correctly and your queries need to be very exact. Also setting up proper caching helps tremendously via the database. Set up triggers that will cache either the whole query or parts of it that reset the cache on a row change or update.
Thank you guys! I was reading about the late row lookup however i solved the problem with count and cache the count of items and then create my own paginator which is limited for 500 pages. With this solution i dont have to care about performance and everything works fine even with using offset.
@jekinney One more question to cache... I use redis driver for cache so it should store everything into the memory... Is there some way how to check how much memory is used for caching stored data, queries for example?
There is remote monitoring software that can display that information either on your sites backend or their website. I haven't personally implemented it as usually most hosting have some sort of monitoring system built in.