나는 a posting on the MySQL forums from 2005을 찾았지만 그보다 더 최근의 소식은 없습니다. 그것을 바탕으로 불가능합니다. 그러나 많은 것이 3-4 년 안에 바뀔 수 있습니다.MySQL에서 인덱스 된 뷰를 사용할 수 있습니까?
내가 찾고있는 방법은보기에 대해 색인을 갖고 있지만 표시되는 표의 색인을 해제하는 방법입니다. 인덱싱은 글쓰기 과정을 아프게하며이 테이블은 인덱싱이 모든 것을 크롤링 속도를 늦추는 지점까지 자주 작성됩니다. 그러나이 색인이 없으면 내 쿼리가 고통스럽게 느려집니다.
MySQL이 필요로하는 구체화 된보기를 지원한다고 생각하지 않지만 어쨌든이 상황에서 도움이되지는 않습니다. 인덱스가 뷰 또는 기본 테이블에 있는지에 관계없이 기본 테이블을 업데이트하는 동안 어느 시점에서 작성되고 업데이트되어야하므로 쓰기 속도 문제가 여전히 발생합니다.
아마도 가장 좋은 방법은 주기적으로 업데이트되는 요약 테이블을 만드는 것입니다.
감사합니다. 구체화 된 뷰에 대해 더 많은 검색을 수행 했으므로 올바른 것으로 보입니다. –
분석 처리 데이터의 트랜잭션 처리 데이터를 추상화하여 고유 한 요구 사항을 충족하도록 특수화 할 수 있다고 생각하십니까?
기본 아이디어는 정기적으로 수정되는 데이터 버전이 하나 있다는 점입니다.이 버전은 트랜잭션 처리 측이 될 수 있으며 쓰기 작업이 빠르기 때문에 과도한 표준화 및 라이트 인덱스가 필요합니다. 데이터의 두 번째 버전은 분석 처리를 위해 구조화되어 있으며 신속한보고 작업을 위해 덜 정규화되고보다 많이 색인화되는 경향이 있습니다.
분석 처리를 기반으로 구조화 된 데이터는 일반적으로 큐브 측면을 나타내는 팩트 테이블과 큐브 가장자리를 나타내는 차원 테이블로 구성된 데이터웨어 하우징의 큐브 방법론을 기반으로 구축됩니다.
그게 사실 내가 지금하고있는 일입니다. 나는 생각한다. 필자는 필요한 데이터가있는 테이블을 쿼리에 대해 인덱스 된 정기적으로 업데이트하므로 인덱싱 된 테이블을 업데이트 할 때마다 인덱스 화되지 않은 테이블을 한 번만 쿼리하면됩니다. 새로운 데이터. –
인덱싱 된 뷰는 하나만 필요합니까? 단 하나의 색인을 가진 테이블에 쓰는 것이 방해가 될 것 같지는 않습니다. 기본 키가 없습니까?
각 레코드가 큰 경우 레코드 길이를 줄이는 방법으로 성능을 향상시킬 수 있습니다. 또는 필요한 색인의 길이를 줄이십시오.
쓰기 전용 테이블 인 경우 (즉, 업데이트 할 필요가없는 경우) MySQL에서 치명적인 결과를 초래할 수 있습니다. 그렇지 않으면 인덱스 (인덱스 키)를 삭제하거나 레코드를 삭제하고 색인을 시작해야합니다 새 인덱스 값을 추가하는 대신 삭제 된 키에서 슬롯을 채 웁니다. 직관력이 없지만이 경우 큰 테이블을 사용하는 것이 좋습니다.
Flexviews은 기본 테이블의 변경 사항을 추적하고 구체화 된보기로 기능하는 테이블을 업데이트하여 MySQL의 구체화 된보기를 지원합니다. 이 접근법은 뷰가 지원하는 SQL이 약간 제한되어 있음을 의미합니다 (변경 로깅 루틴은 변경 사항을 추적해야하는 테이블을 파악해야 함). 그러나 이것이 가장 가까운 것으로 알고있는 한 MySQL에서 구체화 된 뷰를 얻을 수 있습니다 .
참조 http://stackoverflow.com/q/7922675/632951 – Pacerier