Mysql paging performance exploration

Paging is often used in our programming. This article will lead everyone to discuss the performance of mysql paging, hoping to help everyone.

Several common paging methods:

1. Escalator method

The escalator method usually only provides two modes of previous page/next page in navigation. Some products do not even provide the previous page function, only provide a "more/more" method, and there are also drop-down automatic loading. More methods can technically be summarized as escalator methods.
The escalator method is relatively simple and efficient in terms of technical implementation. Just get one page further based on the offset of the last item on the current page. Written as SQL it may be similar to

SELECT*FROMLIST_TABLEWHEREid> offset_id LIMIT n;

1. Elevator method

Another data acquisition method is reflected in the product as a precise page turning method, such as 1,2,3...n. At the same time, the user can also input directly to n pages in the navigation. Most scenes in China use elevators, but the technical implementation cost of elevators is relatively high.

In MySQL, the b-tree usually mentioned is usually b+tree in terms of storage engine implementation.

When using the elevator method, when the user specifies to turn to the nth page, there is no direct method to address the location. Instead, it needs to count one by one from the first floor and scan to count*page to obtain the data. It has just started, so the efficiency is not high.

Traditional paging technology (elevator method)

First, the front end needs to pass you the paging entity and query conditions

//分页实体
structFinanceDcPage{
1:i32 pageSize,//页容量
2:i32 pageIndex,//当前页索引
}

Then you need to return the total number of queries to the front end;

SELECTCOUNT(*)FROMmy_tableWHEREx= y ORDERBYid;

Then return the number of items on the specified page To the front-end:

SELECT*FROMmy_tableWHEREx= y ORDERBYdate_colLIMIT (pageIndex - 1)* pageSize, pageSize;

The results queried from the above two sql statements need to be returned to the front-end paging entity and the single-page result set

//分页实体
structFinanceDcPage{
1:i32 pageSize,//页容量
2:i32 pageIndex,//当前页索引
3:i32 pageTotal,//总页数
4:i32 totalRecod,//总条数
}

In the traditional query method, only the pageIndex value changes with each request, which is the offset of limit offset, num

For example, limit 0,10; limit 10, 10; …. limit10000,10;

The above changes will cause a deviation in the execution time of each query. The larger the offset value, the longer it takes. For example, limit10000,10 needs to read 10010 pieces of data. Only then can you get the 10 pieces of data you want.

Optimization method

In the traditional method, we learned that the key to efficiency is that the program traverses a lot of unnecessary data and finds the key Click So start here.

If there is no need to use the elevator, we can use the escalator to improve performance.

But in most cases, the elevator form can better meet the needs of users, so we need to find another way to optimize the elevator form.

Optimization based on traditional methods

The optimization methods mentioned above are either difficult to meet the needs of users or too complicated to implement, so If the amount of data is not particularly large, such as millions of pieces of data, there is actually no need to use the above optimization method.

The traditional method is sufficient, but the traditional method may also need optimization. For example:

orderby optimization

SELECT*FROMpa_dc_flowORDERBYsubject_codeDESCLIMIT100000,5

The ORDERBY keyword is used in this statement , then what to sort is very important. If you are sorting auto-incrementing IDs, then this statement does not need to be optimized. If it is an index or even a non-index, then it needs to be optimized.

First of all, you have to make sure it is an index, otherwise it will be really slow. Then if it is an index, but it is not as ordered as an auto-incrementing ID, then it must be rewritten as the following statement.

SELECT*FROMpa_dc_flowINNERJOIN(SELECTidFROMpa_dc_flowORDERBYsubject_codeDESCLIMIT100000,5)ASpa_dc_flow_idUSING(id);

The following is the EXPLAIN for two sql

We can see from the picture that the second sql can scan many fewer pages.

In fact, this involves the optimization issue of order by. The subject_code index is not used in the first sql. If you select subject_code instead... the index is used. The following is the optimization of order by.

order by后的字段，如果要走索引，须与where 条件里的某字段建立复合索引！！或者说orcerby后的字段如果要走索引排序，它要么与where条件里的字段建立复合索引【这里建立复合索引的时候，需要注意复合索引的列顺序为（where字段，order by字段），这样才能满足最左列原则，原因可能是order by字段并能算在where 查询条件中！】，要么它自身要在where条件里被引用到！

表asubject_code为普通字段,上面建有索引,id是自增主键

select*fromaorderbysubject_code//用不上索引
selectidfromaorderbysubject_code//能用上索引
selectsubject_codefromaorderbysubject_code//能用上索引
select*fromawheresubject_code= XX orderbysubject_code//能用上索引

意思是说order by 要避免使用文件系统排序，要么把order by的字段出现在select后，要么使用order by字段出现在where 条件里，要么把order by字段与where条件字段建立复合索引！

第二条sql就是巧妙的利用第二种方式利用上了索引。 select id from a order bysubject_code，这种方式

count优化

当数据量非常大时，其实可以输出总数的大概数据，利用explain语句，他并没有真正去执行sql，而是进行的估算。

相关推荐：

MySQL分页性能优化指南

php mysql分页类(php新手入门)

php+mysql分页代码详解_PHP教程

The above is the detailed content of Mysql paging performance exploration. For more information, please follow other related articles on the PHP Chinese website!