WordPress에서 제공하는 각 페이지의 시작 부분에는 옵션을 가져 오기위한 MySQL 호출이 있습니다.
SELECT option_name, option_value FROM wp_options WHERE autoload = 'yes';autoload열에 인덱스가 없으므로 MySQL은 모든 행을 찾아야합니다.
또한 인덱스가 있어도 성능 향상이 없을 것이라고 말하는 이 답변에 대한 의견을 보았습니다.
내 응용 프로그램에서 세션 교체로 많은 과도 값을 사용했습니다. 그들은 훌륭하게 일했고 내 가비지 수집 루틴이 있습니다. wp_options표에서 과도 값 (로 시작하는 값 _transient_)이 모두 있음을 알았습니다 autoload=no. wp_options동시 사용자 수가 증가함에 따라 테이블 의 행 수가 증가 할 것으로 예상합니다 .
왜 테이블이 이런 식으로 설계되어 있는지 알고 싶습니다. 특정 사례에 대한 색인을 만들어야합니까?
답변:
그 필요성은 결코 강하지 않았기 때문에 색인이 없습니다.
에서 티켓 # 14258 이 제안되었다, 그러나 대부분의 옵션을 사용하기 때문에 autoload=yes기본적으로 인덱스는 어쨌든 무시 될 것이다.
여전히 공개 티켓 # 24044 _ 퍼포먼스를 향상 / 개선하기 위해 wp_options에 인덱스 추가 _가 있습니다.
인덱스를 만들어야한다고 생각합니다. 업그레이드 후에도 유지됩니다. 성능에 도움이되지는 않지만 해당 티켓에 실제 통계 데이터를 추가 할 수 있습니다.
2019 년 11 월 업데이트
색인이 WordPress 5.3에 추가되었습니다. 드디어. 위에서 언급 한 티켓 # 24044 및 릴리스에 대한 개발자 노트를 참조하십시오 .
이름이 같은 기존 색인이 있으면 업그레이드 중에 경고가 표시됩니다.
로부터 변경 집합 :
대부분의 사이트는이 변경으로 인해 영향을받지 않지만 행 수가 많고
wp_options소수만autoload설정된 사이트는 성능이 크게 향상됩니다.
행 수가 많은 사이트 중wp_options많은 행 을autoload설정 한 사이트는 불행히도 이미 실행중인 매우 느린 쿼리에 비해 성능 저하가 발생하지만 이는 소수입니다.
wp_options.autoload . 출처 : make.wordpress.org/core/2019/10/15/… ... 그리고 ... core.trac.wordpress.org/ticket/24044#comment:87 ... 이 기능을 제안한 @DanBUK 에게 2013 년
Debian Squeeze 대형 인스턴스에서 3 개의 WP 블로그를 실행 중이며 mysql이 200에서 CPU 사용률과 3과 6 사이의 시스템로드로 호스트에 갇힌 이유를 조사하고있었습니다 .mysql 내부의 'show process list'를 보면 wp_option 테이블 이이 문제와 관련되어 있으므로 다음을 실행했습니다.
alter table wp_options add index autoload_idx(`autoload`);이 작업 후에 상단에 표시된 mysql로드가 1 %로 크게 떨어지고 인스턴스로드 평균은 이제 0.10입니다.
우리는 코드에 어딘가에 루프가있을 수 있도록 일부 플러그인을 사용하고 있으며 이것은 특별한 상황 일 수 있지만 성능의 변화는 완전히 놀랍습니다.
wp_options 테이블에는 347 개의 행이 있습니다.
select *한 번만 해야 합니다. 대신 각 옵션을 쿼리하므로 인덱스를 넣으면 큰 차이가 있습니다.
@fuxia 가 일부 "청구 된"이유 (대부분의 Trac 티켓 등에서 Automattic 직원이 주장한 이유)에 대한 답변을 수락 했지만 WordPress Core가 표 내의 자동로드 옵션에 대한 색인을 포함하지 않는 근본적인 이유wp_options 는 다음과 같습니다. Automattic은 여전히 MyISAM 엔진을 사용하고있는 MySQL 데이터베이스의 성능에 부정적인 영향을 줄 것이라고 걱정했습니다.
특히, 이들은 매우 오래된 / 복잡한 데이터베이스 인 WordPress.org 웹 사이트를 지적했으며 이러한 인덱스로 인해 성능이 저하 될 수있는 예제 웹 사이트입니다.
지난 9 년간 인덱스를 추가하지 않은 거의 모든 다른 이유 (예 : Trac 티켓 # 14258 의 경우 2010 년 이후 및 Trac 티켓 # 24044 의 경우 2013 년 이후 )는 수십 명의 회원에 의해 반복적으로 부정확 한 것으로 입증되었습니다. WordPress 커뮤니티, 그러나 Automattic 직원은 여러 개의 독립적 인 벤치 마크 테스트를 반복적으로 무시하고 MyISAM 문제에 대한 언급으로 되돌아 왔습니다.
고맙게도, 2019 년 후반 PHP 7.2 에서는 WordPress Core에서 권장하는 "기본"버전이, InnoDB 엔진은 이제 5.5 이후 MySQL 버전으로 기본 설정되며 @DanBUK를 포함한 여러 개발자의 지속적인 압박에 의해 수년간 문제를 겪었습니다. Automattic은 마침내 2019 년 11 월 WordPress 5.3+부터 자동로드 인덱스를 추가하기로 결정했습니다.
LittleBizzy에서 우리는 첫 번째 알려진 플러그인을 시작했습니다 인덱스가 존재하지 않는 경우 자동으로 인덱스를 추가 을 은 GitHub에서 계속 사용 가능하며 정기적으로 다운로드됩니다. WP Core 5.3 이상을 실행하는 경우 더 이상 워드 프레스 스택에 이러한 플러그인을 설치할 필요가 없습니다.
autoload열에 인덱스를 설정하고 있습니다.