# Deep Paging Analysis (Continued...)

+ `LIMIT M, N`
  + `M`: return the offset of the record row (OFFSET)
  + `N`: Maximum number of rows to return

------------------------------------------------------------
We found that when the offset of LIMIT is larger, the longer the SQL execution time, look at the following execution plans separately:

(omitted)

As you can see from the execution plan, when LIMIT is 50000000,10, the optimizer estimates that the index scanned 50000010 row. Scanning such a large amount of data explains the slow execution. Why does LIMIT 50000000,10 scan so much data? Here is a brief explanation of LIMIT M, N, the first parameter M is the offset of the return record row (OFFSET), and the second parameter N is the maximum number of rows return. If only one parameter is given, it indicates the maximum number of row return, equivalent to M being 0. LIMIT M, N is to scan and skip M (OFFSET) rows of data row by row according to the specified order, and then fetches up to N row of data.

In our example above LIMIT 50000000,10, OFFSET is 50000000, then TiKV needs to scan 50000010 data and return it to the TiDB layer, sort according to the primary key ID, so the primary key index is used (ordered), TiDB gets the data and skips 50000000 row by line. After records, take the next 10 records. This is why when OFFSET is large, SQL execution is slow. First, the TiKV layer needs to return a lot of data to TiDB, and then TiDB also needs to scan and skip a lot of data, and finally only take the required 10 records. Judging from this SQL, the cost of fetching 10 data is really too high, so what should we do How about solving this problem? The idea is to try to avoid OFFSET or OFFSET with a lot of data.