MySQL 페이징 성능 탐색

小云云원래의: 2017-12-08 11:52:261499검색

페이징은 프로그래밍에서 자주 사용됩니다. 이 기사에서는 모든 사람에게 도움이 되기를 바라면서 MySQL 페이징의 성능에 대해 논의하게 됩니다.

몇 가지 일반적인 페이징 방법:

1. 에스컬레이터 방법

에스컬레이터 방법은 일반적으로 탐색에서 이전 페이지/다음 페이지 모드만 제공하며 일부 제품은 이를 제공하지도 않습니다. 페이지 기능은 "더보기/더보기" 방식만 제공하며 자동으로 더 많이 불러오는 풀다운 방식도 있는데, 이는 기술적으로는 에스컬레이터 방식으로 요약할 수 있습니다.
에스컬레이터 방식은 기술적인 구현 측면에서 상대적으로 간단하고 효율적입니다. 현재 페이지의 마지막 항목 오프셋을 기준으로 한 페이지만 더 이동하면 됩니다. SQL로 작성하면

SELECT*FROMLIST_TABLEWHEREid> offset_id LIMIT n;

과 유사할 수 있습니다. 1. 엘리베이터 방식

또 다른 데이터 획득 방식은 1,2와 같은 정밀한 페이지 넘김 방식으로 제품에 반영됩니다. ,3...n과 동시에 사용자가 내비게이션의 n페이지에 직접 입력할 수도 있습니다. 중국의 대부분의 장면은 엘리베이터를 사용하지만 엘리베이터의 기술 구현 비용은 상대적으로 높습니다.

MySQL에서 일반적으로 언급되는 b-트리는 스토리지 엔진 구현 측면에서 b+tree입니다.

엘리베이터 방식을 사용할 때 사용자가 n번째 페이지로 이동하도록 지정하면 위치를 지정하는 직접적인 방법이 없으며 대신 1층에서 하나씩 계산하고 스캔하여 페이지를 계산해야 합니다. 그러면 데이터 수집이 실제로 시작됩니다. 따라서 효율성은 높지 않습니다.

전통적인 페이징 기술(엘리베이터 방식)

먼저 프런트 엔드에서 페이징 엔터티와 쿼리 조건을 전달해야 합니다.

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

그런 다음 총 쿼리 수를 앞쪽으로 반환해야 합니다. -end;

SELECTCOUNT(*)FROMmy_tableWHEREx= y ORDERBYid;

그런 다음 지정된 페이지 수를 프런트 엔드에 반환합니다.

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

위의 두 SQL 문으로 쿼리한 결과를 프런트 엔드 페이징 엔터티로 반환해야 합니다. 및 단일 페이지 결과 세트

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

기존 쿼리 방법에서는 각 요청마다 pageIndex 값만 변경됩니다. 즉, 제한 오프셋, num

오프셋(예: 제한 0,10); ,10; ....limit10000,10;

위 변경으로 인해 각 쿼리의 실행 시간에 편차가 발생합니다. 예를 들어,limit10000,10은 10010을 읽어야 합니다. 원하는 10개의 데이터를 얻기 위한 데이터 조각입니다.

최적화 방법

전통적인 방법에서는 프로그램이 불필요한 데이터를 많이 순회하는 것이 효율성의 핵심이라는 것을 배웠고, 핵심을 찾으면 여기서 시작하세요.

엘리베이터를 사용할 필요가 없다면 에스컬레이터를 이용하여 성능을 향상시킬 수 있습니다.

그러나 대부분의 경우 엘리베이터 형태는 사용자의 요구를 더 잘 충족할 수 있으므로 엘리베이터 형태를 최적화할 수 있는 다른 방법을 찾아야 합니다.

기존 방법에 따른 최적화

위에서 언급한 최적화 방법은 사용자의 요구를 충족하기 어렵거나 구현하기가 너무 복잡하므로 데이터 양이 수백만 개와 같이 특별히 크지 않은 경우. 실제로 위의 최적화 방법을 사용할 필요가 전혀 없습니다.

전통적인 방법으로도 충분하지만 최적화가 필요할 수도 있습니다. 예:

orderbyoptimization

SELECT*FROMpa_dc_flowORDERBYsubject_codeDESCLIMIT100000,5

ORDERBY 키워드가 이 문에 사용되므로 정렬 대상이 매우 중요합니다. 자동 증가 ID를 정렬하는 경우에는 필요하지 않습니다. 문을 최적화하려면 인덱스이거나 인덱스가 아닌 경우에도 최적화해야 합니다.

먼저 색인이 생성되었는지 확인해야 합니다. 그렇지 않으면 정말 느려질 것입니다. 그런 다음 인덱스이지만 자동 증가 ID만큼 순서가 지정되지 않은 경우 다음 명령문으로 다시 작성해야 합니다.

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

다음은 두 개의 SQL에 대한 EXPLAIN입니다

두 번째 SQL이 훨씬 적은 수의 페이지를 스캔할 수 있다는 것을 그림에서 볼 수 있습니다.

실제로 이는 order by의 최적화 문제와 관련이 있습니다. 첫 번째 SQL에서는 subject_code 인덱스가 사용되지 않습니다. 대신 subject_code를 선택하면... 색인이 사용됩니다. 다음은 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 페이징 성능 탐색

관련 기사