MariaDB/MySQL tmp 테이블이 전체 디스크 공간을 사용하고 있습니다.
약 4GB 크기의 데이터베이스가 하나 있고, GROUP_BY, GROUP_CONCAT 등의 너무 복잡한 보기가 하나 있습니다.
이 보기를 쿼리할 때 MariaDB10이 디스크 임시 파일(/tmp)에 생성되는 경우가 있습니다.파일 크기가 40GB 이상입니다. 끝이 없는 것 같습니다.이러한 파일이 생성되는 이유는 이해하지만, 왜 이 파일이 우리가 가지고 있는 모든 데이터보다 큰지는 이해할 수 없습니다.
재귀적 결합이 그것의 원인일 가능성이 있습니까?왜 매번 일어나는 것이 아니라 가끔 일어나는 것일까요?(캐시 크기, 버퍼 ?)
구성을 통해 이러한 상황을 방지할 수 있는 방법이 있습니까?이런 종류의 테이블은 얼마나 클 수 있습니까?
저는 아마 발굴을 통해 이유를 찾았을 것입니다: https://www.percona.com/blog/2007/08/12/mysql-view-as-performance-troublemaker/
사용자들이 공유한 이야기와 함께 신선한 댓글이 달린 오래된 게시물입니다.Massimiliano Alessandri는 MySQL에서 VIEW를 사용하면 생성된 결과 세트가 Disk에 기록된 다음 GB 단위의 데이터로 인덱스 없이 검색된다고 지적했습니다.그것은 또한 우리의 문제인 것 같습니다.이에 대한 유일한 해결책은 VIES를 사용하지 않는 것입니다.
바이너리 로그가 활성화된 것 같습니다.다음 SQL 명령을 사용하여 제거를 시도할 수 있습니다.
PURGE BINARY LOGS BEFORE NOW();
https://dev.mysql.com/doc/refman/8.0/en/purge-binary-logs.html
언급URL : https://stackoverflow.com/questions/41726514/mariadb-mysql-tmp-tables-are-eating-up-whole-disk-space
'programing' 카테고리의 다른 글
시간을 변환합니다.문자열 작성 시간 (0) | 2023.09.03 |
---|---|
jquery "$post" 요청을 동기화하는 방법 (0) | 2023.09.03 |
jAJAX로 Google 시각화 API 로드 (0) | 2023.09.03 |
휴일과 주말을 제외한 두 날짜 사이의 날짜를 어떻게 계산합니까? (0) | 2023.09.03 |
CORS(심포니, jQuery, FOSRest 번들 및 Nelmio Cors 번들 포함) (0) | 2023.09.03 |