많은 수의 internal temporary disk tables이 쓰여지고있는 것을보고 있습니다. SHOW GLOBAL STATUS where Variable_name like 'Created_tmp_disk_tables'으로 계산됩니다.MySQL 내부 innodb 임시 테이블의 크기를 보는 방법
이 문제를 방지하기 위해 max_heap_table_size과 tmp_table_size을 업데이트 할 수 있지만 디스크에 기록되는 테이블의 크기를 알지 못하면 어떤 값을 사용해야하는지 알기가 어렵습니다.
누구든지이 값을 찾는 방법을 알고 있습니까?
이것은 쉽지 않습니다. Percona Server에서 임시 테이블의 크기를 보여줍니다 슬로우 쿼리 로그에 추가 정보를 추가 할 수있는 옵션 (https://www.percona.com/doc/percona-server/5.7/diagnostics/slow_extended.html 참조)
# [email protected]: mailboxer[mailboxer] @ [192.168.10.165]
# Thread_id: 11167745 Schema: board
# Query_time: 1.009400 Lock_time: 0.000190 Rows_sent: 4 Rows_examined: 1543719 Rows_affected: 0 Rows_read: 4
# Bytes_sent: 278 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0
# QC_Hit: No Full_scan: Yes Full_join: No Tmp_table: No Tmp_table_on_disk: No
# Filesort: No Filesort_on_disk: No Merge_passes: 0
Oracle MySQL에서는 PERFORMANCE_SCHEMA-의 쿼리 이벤트에서 동일한 확장 정보를 사용할 수 있지만 임시 테이블 크기.
2014 년에이 정보를 제공하라는 기능 요청이 기록되었습니다 : https://bugs.mysql.com/bug.php?id=74484이 버그는 인정되었지만 알고있는 한 구현되지 않았습니다.
특정 쿼리가 여러 크기의 임시 테이블을 만드는 것이 가능하기 때문에 이것이 어떻게 구현되는지는 분명하지 않습니다. Percona 기능은 이러한 경우 임시 테이블 크기의 총합을 표시합니다.
모든 제안은 Created_tmp_tables (디스크를 사용하지 않은 임시 테이블)에 비해 단위로 max_heap_table_size 및 tmp_table_size을 높이고, SHOW GLOBAL STATUS에 의해보고 된 Created_tmp_disk_tables의 증가율을 모니터링하는대로 내가 제공 할 수 있습니다. 허용 된 tmp 테이블 크기가 생성되는 임시 테이블의 더 큰 비율을 유지할 수 있으므로 디스크상의 임시 테이블과 인 메모리 임시 테이블의 비율이 감소하는 것을보아야합니다.
일반적으로 tmp_table_size을 늘려서 을 유지할 필요가 없습니다. 얼마나 큰지간에 가능한 임시 테이블마다. 가장 큰 이상 치를 사용하려면 디스크를 사용하십시오. 그러나 임시 테이블이 98 %의 시간 동안 메모리를 사용하는 한 괜찮습니다. 이는 Created_tmp_disk_tables 대 Created_tmp_tables의 비율이 1:50 이상이어야 함을 의미합니다.
테이블의 작은 비율 (1 % 미만)이 디스크에 기록되는 것처럼 보입니다. 그러나 하루에 약 1GB의 데이터가 생성되는 것 같습니다. 디스크 임시 테이블에서 사용하는 공간을 다시 확보 할 수있는 유일한 방법은 데이터베이스를 다시 시작하는 것입니다. – sager89
https://dev.mysql.com/doc/refman/5.7/en/innodb-temporary-tablespace.html에 따르면 tmp 테이블 스페이스는 완전 종료 중에 제거되므로 예, 재시작해야합니다. 어떤 사람들은'default_tmp_storage_engine = MyISAM'을 설정하여 InnoDB tmp 테이블 공간을 피하도록합니다. –
그냥 설명서의 내용을 살펴보고 테이블 수가 충분하지 않다는 것을 알고 있다면 (Created_tmp_tables) tmpdir 변수는이 테이블을 저장하는 디렉토리의 위치를 알려줍니다. tmp_table_size을 낮추면 디스크에 임시 테이블이 생성되므로 크기를 볼 수 있습니다.
은 (부칙 빌의 대답.)
몇 가지 중요한 변화는 TMP 테이블의 취급 5.7 및 8.0되었습니다. 나는 그들 중 누구도 여기에 적용되지만 잘 알고 있는지 모르겠습니다. TEXT, BLOB, @variables, UNION 등 -
tmp_table_size는 디스크 기반의 임시 테이블을 사용하는 유일한 이유되지 초과(자세한 내용은 https://dev.mysql.com/doc/refman/5.7/en/internal-temporary-tables.html) 그 이유 때문에 Bill의 1시 50 분 충고에 의문을 제기합니다.
Tmp 테이블 (디스크 상 또는 메모리 내)은 많은 쿼리로 생성 될 수 있습니다. 복합 조회의 경우 여러 개의 tmp 테이블이 필요할 수 있습니다. 따라서 동시 tmp 테이블의 수는 이고이 max_connections 이상일 수 있습니다. 이러한 이유로 tmp_table_size을 사용 가능한 RAM의 1 % 미만으로 유지하는 것이 좋습니다. 과에 많은 수의 동시 tmp 테이블이 필요하다면 성능을 크게 저하시키는 스와핑이 발생할 수 있습니다.
Created_tmp*tables에는 높은 값을 갖는 데 많은 "수정 사항"이 있습니다. 여기에 항목을 너무 많이 넣었습니다. 검색어 (및 관련 SHOW CREATE TABLEs)를 제출하려면 우리는 그 특별한 경우를 토론 할 수 있습니다. analyzing 고객의 시스템, 나는 그런 내 생각에
Created_tmp_disk_tables > 1/second
Created_tmp_disk_tables > 4% of queries
Created_tmp_tables > 20/second
사람들의 모든 같은 것들을 볼 때
은 느린 쿼리의 조사에 대한 필요성을 나타냅니다. 그러나 tmp_table_size이 RAM의 1 %보다 큰 경우 쿼리가 손상 되더라도 RAM을 낮추는 것이 좋습니다.
어떤 버전의 MySQL/Aurora를 사용하고 있습니까? –
오로라 버전 1.14.1 – sager89