Method 1: Directly use the SQL statement provided by the database
--- Statement style : In MySQL , the following methods can be used : SELECT * FROM table name LIMIT M,N .
--- Adapted to the scene : suitable for the case of a small amount of data ( tuple hundred / thousand level ) .
--- Reason / disadvantage : full table scan , the speed will be very slow and some database result sets return unstable ( such as returning 1,2,3 for one time, and 2,1,3 for another time ) . Limit restricts the N outputs from the M position of the result set , and discards the rest.
Method 2: Establish a primary key or unique index and use the index ( assuming 10 entries per page )
--- Statement style : In MySQL , the following methods can be used :
SELECT * FROM table name WHERE id_pk > (pageNum*10) LIMIT M .
--- Adapted to the scene : suitable for the case of a large amount of data ( tens of thousands of tuples ) .
--- Reason : Index scan , the speed will be very fast. Some friends suggested that because the data query is not sorted according to pk_id , there will be a case of missing data, only method 3 .
Method 3: Reorder based on index
--- Statement style : In MySQL , the following methods can be used : SELECT * FROM table name WHERE id_pk > (pageNum*10) ORDER BY id_pk ASC LIMIT M .
--- Adapted to scenarios : It is suitable for situations with a large amount of data ( tens of thousands of tuples ). It is best that the column object after ORDER BY is the primary key or unique , so that the ORDERBY operation can be eliminated by using the index but the result set is stable ( For the meaning of stability , see method 1) .
--- Reason : Index scan , the speed will be very fast . But MySQL 's sorting operation , only ASC without DESC (DESC is false , will do real DESC in the future, look forward to ) .
Method 4: Use prepare based on the index (the first question mark means pageNum , the second ? means the number of tuples per page)
--- Statement style : In MySQL , the following methods can be used :
PREPARE stmt_name FROM SELECT * FROM 表名称 WHERE id_pk > (？* ？) ORDER BY id_pk
ASC LIMIT M。
--- Adapt to the scene : large amount of data.
--- Reason : index scan , the speed will be very fast . The prepare statement is a little faster than the general query statement.
Method 5: Using MySQL to support ORDER operations can use indexes to quickly locate some tuples and avoid full table scans
--- Example : read the tuple of rows 1000 to 1019 (pk is the primary key / unique key ) .
---SELECT * FROM your_table WHERE pk>=1000 ORDER BY pk ASC LIMIT 0,20。
Method 6: Use " subquery / join + index " to quickly locate the position of the tuple , and then read the tuple . The reason is the same as method 5
--- Such as (id is the primary key / unique key , variable in blue font ):
Example using subqueries :
|
|
SELECT * FROM your_table WHERE id <= (SELECT id FROM your_table ORDER BY id desc LIMIT ($page-1)*$pagesize ORDER BY id desc LIMIT $pagesize |
Exploit connection example :
|
|
SELECT * FROM your_table AS t1 JOIN (SELECT id FROM your_table ORDER BY id desc LIMIT ($page-1)*$pagesize AS t2 WHERE t1.id <= t2.id ORDER BY t1.id desc LIMIT $pagesize; |
Method 7: Stored procedure class (preferably combining the above methods 5/6 )
--- Statement style : no longer given
--- Adapt to the scene : large amount of data . The method recommended by the author
--- Reason : The operation is encapsulated in the server, which is relatively faster.
Method 8: The reverse method
--- Someone on the Internet wrote to use SQL_CALC_FOUND_ROWS . It doesn't make sense, don't imitate it .
Basically , it can be generalized to all databases , the reason is the same. However, method 5 may not be generalized to other databases . The premise of generalization is that other databases support the ORDER BY operation and can use the index to directly complete the sorting.