1. WP_Query를 실행 하기 전에 쿼리 를 설정하십시오.
물론 쿼리를 변경할 수있는 유일한 기회는 SQL 데이터베이스에서 실행하기 전에 쿼리를 변경하기 때문에 데이터베이스 쿼리를 최소로 유지하려고 할 때 명심해야 할 가장 중요한 것 같습니다.
일반 쿼리
일반 쿼리의 경우 WordPress는이 wp()함수를 사용하여이 함수를 호출합니다 $wp->main( $query_vars ). 조건부 태그의 "is_ 변수"는로 전달하기 전에 설정 WP_Query->get_posts()되어 MySQL 데이터베이스 쿼리로 변환 한 다음 $ wp_query 객체에 저장합니다. 실제로 SQL 데이터베이스 에서 실행되기 전에 쿼리를 필터링 할 수 있습니다 .
pre_get_posts조치는가 전달되기 전에 쿼리를 변경할 수 있도록,이 과정에 후크 WP_Query->get_posts().
예를 들어 "추천"범주의 게시물에 대한 쿼리를 필터링하려면 add_action( 'pre_get_posts', 'your_function_name' );에 in_category조건부 태그를 사용 하고 포함합니다 your_function_name.
function your_function_name( $query ) {
if ( $query->in_category( 'featured' ) && $query->is_main_query() ) {
// Replace 123 with the category ID of the featured category.
$query->set( 'cat', '123' );
}
}
add_action( 'pre_get_posts', 'your_function_name' );
참조 플러그인 API / 액션 참조 / 게시물«워드 프레스 코덱스를 얻을 사전
페이지 요청
"기능"카테고리의 아카이브 페이지와 같은 페이지 템플리트의 경우 조건부 태그가 pre_get_posts필터 에서 작동하지 않습니다 . 예를 들어, is_categoryWP_Query가 실행되지 않았으므로 아카이브 페이지를 확인 하는 데 사용할 수 없습니다 .
대신 페이지 요청에 대한 기본 쿼리를 new WP_Query다음과 같이 변경해야 $query = new WP_Query( 'cat=123' );합니다. 시작부터 적절한 인수 세트로 조회를 실행합니다.
참조 클래스 참조 / WP 쿼리«워드 프레스 코덱스
2. 데이터베이스에 저장
이 필터를 사용하면 wp_insert_post_data맞춤 게시물 유형과 관련된 $ data 만 (으)로 반환됩니다 wp_insert_post. 맞춤 게시물 유형을 확인하려면 조건문을 포함해야합니다.
플러그인 API / 필터 참조 / wp 삽입 게시물 데이터«워드 프레스 코덱스
이 후크는 wp_insert_post함수에 의해 호출되며 사용자 정의 게시물 유형을 업데이트 할 때 일반적으로 초안을 저장하거나 게시물을 게시하여 wp_update_post에 의해 호출됩니다 .
데이터베이스에서 업데이트되는 데이터를 줄이는 최적화의 중요성에 대해 개인적으로 말할 수는 없지만 직접 벤치마킹해야합니다.
3. 맞춤 게시물 유형이 성능에 영향을 줍니까?
필자의 경험에 따르면 사용자 지정 게시물 유형은 콘텐츠 관리를위한 강력한 도구입니다. 리소스를 덜 사용하는 방식으로 게시물을 관리하는 다른 방법을 모릅니다. 저는 개인적으로 가능한 곳에서 수행되는 쿼리 수를 줄이는 방법을 찾는 데 중점을 둘 것입니다.
퍼머 링크 구조와 관련된 성능 문제로 인해 숫자 대신 텍스트로 시작할 때 적중을 초래했습니다. 3 이는 많은 페이지를 호스팅하는 사이트에서 특히 문제가되었지만 WordPress 버전 3.3 이후로 해결되었습니다.
슬러그는 일반적으로 버전 3.3 이전의 성능에 영향을 미쳤거나 그렇지 않을 수있는 영구 링크 구조의 첫 번째 부분이기 때문에 여기서는 영구 링크 만 표시합니다. 그 외에도 사용자 정의 게시물 유형을 사용하여 발생하는 성능 문제는 알지 못합니다.
다른 성능 옵션
과도
코드에서 쿼리를 최소로 유지하는 것을 대체하는 것은 아니지만 set_transient 를 사용하여 얼마 동안 쿼리를 저장하여 새 쿼리가 필요하지 않을 수 있습니다. 다음은 Dave Clements의 post에 사용 된 예 입니다. 또한 save_post지정된 게시물 유형이 업데이트 될 때마다 임시 작업을 삭제 하는 작업을 추가하는 것이 좋습니다 .
<?php // IN THE SPOTLIGHT QUERY
if( false === ( $its_query = get_transient( 'its_query' ) ) ) {
$pttimestamp = time() + get_option('gmt_offset') * 60*60;
$its_query = new WP_Query( array(
'post_type' => 'spotlight',
'posts_per_page' => 1,
'post__not_in' => $do_not_duplicate,
'meta_query' => array(
array(
'key' => '_hpc_spotlight_end_time',
'value' => $pttimestamp,
'compare' => '>'
)
)
) );
set_transient( 'its_query', $its_query, 60*60*4 );
}
if( have_posts() ) { // HIDE SECTION IF NO CURRENT ITS FEATURE ?>
// LOOP GOES HERE: NOT IMPORTANT TO EXAMPLE
<?php } ?>
더 많은 쿼리 최적화
Thomas Griffin은 자신의 WordPress 쿼리 최적화 자습서 에서 유용한 팁을 몇 가지 제공 합니다. 그의 제안에 대한 간략한 목록은 다음과 같습니다.
설정 'cache_results' => false서버는 Memcached가 같은 영구적 인 캐시를 사용하지 않는 경우 일회성 쿼리. 일회성 쿼리는 "소량의 데이터를 표시하는 데 사용되는 쿼리입니다. 현재 게시물과 관련된 링크 된 게시물 제목 만 표시하거나 선택할 게시물 드롭 다운을 표시 할 수 있습니다. 특정 옵션 설정. "
그의 예 : $query = get_posts( array( 'posts_per_page' => 1,
'cache_results' => false ) );
'no_found_rows' => true페이지 매김이 필요하지 않은 위치를 설정하십시오 . 이것은 "우리가 페이지 매김이 필요한지 아닌지를보기 위해 결과를 세는 MySQL을 우회 할 것이다."
그의 예 : $query = new WP_Query( array( 'posts_per_page' => 1,
'no_found_rows' => true ) );
포스트 ID에 대한 쿼리이 필요한 모든 경우에만 'fields' => 'ids'
에서 get_posts. 이렇게하면 반환되는 데이터의 양이 크게 줄어들어야합니다. 데이터베이스 설명«WordPress Codex 를 보면 게시물 당 상당히 많은 양입니다.
그의 예 : $query = get_posts( array( 'posts_per_page' => 1,
'fields' => 'ids' ) );
마지막 팁 외에도 get_post_field 를 사용하여 하나 또는 몇 개의 포스트 필드 만 필요한 경우 동일한 추론을 적용 할 수 있습니다 .
쿼리 작동 방식을 제대로 이해하는 것이 필수적입니다. 쿼리를보다 구체적으로할수록 SQL 데이터베이스에서 요구하는 작업이 줄어 듭니다. 이는 데이터베이스 쿼리를 관리 할 수있는 많은 가능성이 있음을 의미합니다. 사용자 정의 쿼리는 실행 위치 (관리자 페이지입니까?)까지주의하고, 직접 쿼리에서 적절한 위생 처리 를 사용하고 동일한 성능을 달성 할 수있는 기본 WordPress 기능을 사용하십시오.