MySQL은 Database 작업 성능을 향상하기 위한 다양한 메모리 영역을 갖고 있으며, 각 영역의 값을 변경하여 MySQL 성능을 향상할 수 있습니다. 이러한 메모리 영역은 스토리지 엔진 또는 사용 중인 기능에 따라 다르지만, 일반적으로 공유 가능 여부를 기준으로 Global Memory와 Local Memory 영역으로 구분할 수 있습니다.
Global Memory
Global Memory 영역이란 Client Thread 수와 무관하게 공통으로 사용되는 하나의 메모리 공간을 의미합니다. 단, 필요에 따라 2개 이상의 공간을 할당받을 수도 있지만 생성된 영역이 2개 이상이어도 모든 Thread에서 공유 가능합니다.
Global Memory 영역은 MySQL Server가 시작될 때 운영체제로부터 할당되며, 설정을 변경하는 경우 MySQL Server를 재시작해야합니다.
Global Memory 영역에는 다음과 같은 공간을 포함하며 각 영역에 대해 차례로 설명하겠습니다.
- InnoDB Buffer Pool
- InnoDB Change Buffer
- InnoDB Adaptive Hash Index
- InnoDB Log Buffer
- MyISAM Key Cache
- Query Cache
- Table Cache
InnoDB : Buffer Pool
InnoDB 스토리지 엔진의 가장 큰 메모리 영역인 Buffer Pool에는 Data, 인덱스, Lock, Data Dictionary 및 기타 정보를 저장합니다. (Oracle의 Buffer Cache 영역과 유사합니다.)
주로 자주 사용되는 Data를 메모리 영역에 캐싱해서 빠르게 접근하기 위한 용도로 사용됩니다.
📢 InnoDB Architecture의 In-Memory Structures 내 Buffer Pool 부분에서 자세하게 설명하겠습니다.
InnoDB : Change Buffer(구 버전 - Insert Buffer)
Insert, Update, Delete와 같은 Data 변경 작업 시 사용되는 메모리 영역입니다.
Data 변경 작업 시 인덱스에도 변경 내역이 반영되어야 하는데, 관련 인덱스가 많다면 자원 소모가 커질 수 있습니다. 이러한 이유로 인덱스에 대한 작업 성능 향상을 목적으로 하는 메모리 공간이 바로 Change Buffer입니다.
MySQL 5.5 이전에는 Insert 작업에 대한 변경내역만을 기록하였기 때문에 Insert Buffer라는 이름으로 불렸습니다.
📢 InnoDB Architecture의 In-Memory Structures 내 Change Buffer 부분에서 자세하게 설명하겠습니다.
InnoDB : Adaptive Hash Index
B-Tree Index의 약점을 보완하기 위한 InnoDB의 기능으로, 자주 사용되는 컬럼을 해시로 정의하여 바로 Data에 접근이 가능하게 하는 기능입니다.
이때, 모든 값이 아닌 자주 사용되는 Data 값만 해시 값으로 생성합니다. Adaptive Hash Index 영역에 할당되며 전체 Innodb Buffer Pool의 1/64 만큼으로 초기화됩니다.
📢 InnoDB Architecture의 In-Memory Structures 내 Adaptive Hash Index 부분에서 자세하게 설명하겠습니다.
InnoDB : Log Buffer(구 버전 - Redo Log Buffer)
디스크의 트랜잭션 로그(Redo Log)파일에 기록할 내용을 보관하는 메모리 영역입니다. Log Buffer의 내용은 주기적으로 디스크로 Flush 됩니다. (Oracle의 Redo Log Buffer와 비슷한 역할을 합니다.)
MySQL 5.5 버전까지는 Redo Log Buffer, 이후 버전부터는 Log Buffer라고 명칭 합니다.
📢 InnoDB Architecture의 In-Memory Structures 내 Log Buffer 부분에서 자세하게 설명하겠습니다.
MyISAM : Key Cache
MyISAM의 Key Cache는 InnoDB의 Buffer Pool과 유사한 역할을 하는 메모리 영역으로, MyISAM 테이블의 인덱스를 캐싱하기 위한 공간입니다. (MyISAM 스토리지 엔진에서 Index Block은 Key Cache라는 특수 영역에 캐싱되지만, Data Block의 경우에는 특별한 캐싱 영역이 없으며, 대신 운영체제에서 제공하는 파일 시스템 캐시를 사용합니다.)
Key Cache는 여러 Session에서 동시에 Access 할 수 있으며, 여러 개 설정하거나 특정 캐시에 인덱스를 할당할 수 있습니다.
Key Cache의 크기는
key_buffer_size System Variable로 설정 가능하며, 0으로 설정 시 Key Cache를 사용하지 않습니다. Key Cache를 사용하지 않으면 운영체제에서 제공하는 OS Cache만 사용하여 인덱스 파일에 Access 합니다.Key Cache Hit(%) = 100 - (key_reads / key_read_requests * 100)
- key_reads : 인덱스를 디스크에서 읽어 들인 횟수
- key_read_requests : 인덱스를 키 캐시로부터 읽은 횟수
MyISAM 테이블의 인덱스는 Key Cache를 이용하여 디스크 I/O 없이 빠르게 검색할 수 있지만, 테이블 Access에 대한 디스크 I/O는 발생합니다. 즉, MyISAM 테이블에 대한 Read/Write 작업은 항상 물리적인 I/O를 수반합니다.
공통 : Query Cache
📢 Query Cache는 MySQL 4.0.1에서 도입된 후 MySQL 5.7.20부터 더 이상 사용되지 않으며 MySQL 8.0에서 완전히 제거되었습니다.
Query Cache에는 Client로 전송된 결과 집합과 Select 문장을 함께 저장하고 있습니다.
동일한 Query가 수행되면 MySQL Server는 해당 Query에 대한 Parsing 과정을 수행하는 대신 Query Cache에서 결과를 검색합니다. Query Cache는 Session 간 공유되는 Global Memory 영역에 있기 때문에 특정 Client에서 생성된 결괏값이 다른 Client의 결과로 활용될 수 있습니다.
Query Cache는 자주 변경되지 않는 테이블에 대해 동일한 Query를 자주 사용하는 환경에서 유용합니다. 하지만 테이블이 변경되면 결과값에 대한 보장을 할 수 없으므로 Query Cache에서 관련 항목이 제거됩니다. 또한 테이블 변경으로 인한 Query Cache 제거 과정에서, 유효하지 않은 Data를 가져가지 못하도록 Lock을 걸며, Lock이 해소될 때까지 Query Cache에 Access 하는 모든 Thread는 대기상태를 경험하게 됩니다. 이러한 이유로, 테이블에 대한 변경이 잦고 Query Cache를 사용하는 Select Query가 많을수록 심각한 속도가 느려지는 것을 경험할 수 있습니다.
과거 Query Cache는 상당한 성능 향상 가능성을 제공했었지만, 스토리지 기술의 발전으로 그 이점은 거의 없어졌습니다. 또한 Database 동시성을 저하하거나 일부 버그의 원인이 되기도 하여 8.0 버전부터는 사용이 불가합니다.
공통 : Table Cache
MySQL에서 테이블을 읽고 쓰기 위해서는 항상 테이블을 열고 사용 후에는 닫아야 합니다. 이러한 작업은 부하를 발생시키기 때문에 오픈된 테이블의 정보를 특정 공간에 담아둡니다. 이 공간을 Table Cache라고 하며, Thread들이 공유해서 사용합니다.
하지만 동일한 정보(테이블)에 대한 Thread 간 공유는 불가능하므로, 동일 테이블에 접근하는 Thread가 많을수록 정보를 저장하기 위한 추가 메모리 공간을 필요로 합니다.
MySQL은 다중 Thread로 동작하므로 동일 테이블에 대해 동시에 Query를 수행하는 많은 Client가 있을 수 있지만, 동일 테이블에 대해서는 Thread 간 공유되지 못합니다. 동일 테이블에 접근하는 Thread가 많을수록 더 많은 테이블이 오픈되어야 하므로 추가 메모리를 사용합니다.
Table Cache의 크기는 Server 시작 시 자동으로 설정되지만,
table_open_cache를 통해 명시적으로 조정할 수 있습니다.table_open_cache는 max_connections와도 관련이 있습니다. 예를 들어, 200개의 동시 접속 환경에서는 Table Cache 크기를 200 * N 이상으로 설정합니다. (N은 실행하는 Query에서 조인당 최대 테이블 수입니다.)다음의 경우에는 사용되지 않는 테이블을 Table Cache에서 제거하여 공간을 확보합니다.
- 캐시가 가득 찬 상태에서 Thread가 캐시에 없는 테이블을 오픈하려고 할 때
- Table Cache에
table_open_cache설정 값 보다 많이 담고 있는 상황에서 더 이상 사용되지 않는 Table이 존재하는 경우
flush tables명령어 수행 시
공간을 확보하는 방법은 다음과 같습니다.
- 먼저, 가장 최근에 사용되지 않는 테이블부터 시작하여 현재 사용되지 않는 테이블을 해제하여 공간을 만듭니다.
- 테이블을 해제할 수 없는 경우, 필요에 따라 일시적으로 캐시를 확장하여 공간을 만듭니다. 캐시가 일시적으로 확장된 상태일 때, 테이블이 사용된 상태에서 미사용 상태로 전환되면 테이블이 닫히고 캐시에서 해제됩니다.
Local Memory
Local Memory 영역은 Client Thread가 Query를 처리하는 데 사용하는 개별적인 메모리 공간입니다. Client Thread가 사용하는 공간이라는 의미에서 Client Memory라고도 하며, Client와 MySQL Server와의 Connection을 Session이라고 하기 때문에 Session Memory 라고도 부릅니다.
Local Memory 영역은 Thread 별로 독립적으로 할당되며 공유되지 않습니다. 따라서 Local Memory에 해당하는 값들을 크게 설정할 경우 각 Client Thread가 사용하는 메모리 양이 커져서 Server의 메모리 여유량이 부족해질 수 있습니다. 필요한 경우, 특정 Session에 대해서만 변경해주는 것이 좋습니다.
Local Memory의 각 메모리 영역은 Query 별로 필요한 경우에만 할당되며, 필요하지 않은 경우에는 사용되지 않습니다. Connection Buffer나 Result Buffer의 경우 Connection이 유지되는 동안 할당된 상태로 남아있지만, Sort Buffer나 Join Buffer의 경우 Query를 수행하는 시점에 할당했다가 해제됩니다.
Local Memory 영역에는 다음과 같은 공간이 있으며, 각 영역에 대해 차례로 설명하겠습니다.
- Sort Buffer
- Join Buffer
- Read Buffer
- Connection Buffer & Result Buffer
- Binlog Cache
Sort Buffer
Sort Buffer란 인덱스를 이용한 정렬이 불가능할 경우, 별도의 정렬 작업을 하는데 이때 사용되는 공간입니다. 정렬이 필요할 경우에만 할당되며, Query 실행이 완료되면 시스템에 즉시 반환됩니다.
Sort Buffer의 크기는 시스템 파라미터
sort_buffer_size로 설정할 수 있습니다. 정렬해야 하는 Data의 크기가 Sort Buffer보다 큰 경우에는 정렬 Data를 여러 조각으로 나누어서 처리되며, 임시 저장을 위해 디스크를 사용합니다. 그리고 디스크에 저장된 Data를 다시 메모리로 읽어 처리합니다.Sort Buffer 영역은 각 Session마다 할당되기 때문에 너무 큰 사이즈를 지정하면 메모리 부족 현상을 겪을 수 있으며, 너무 작게 지정하면 대부분의 정렬 작업에 디스크 I/O가 발생하므로 적절한 값으로 설정해야 합니다.
여러 조각으로 나누어진 Data를 정렬하기 위해 디스크에 Write와 Read를 반복하는 것을 Multi-Merge라고 합니다. Multi-Merge 횟수는
sort_merge_passes라는 Status Variable에 누적되기 때문에 모니터링이 가능합니다. Multi-Merge가 발생하게 되면 디스크를 사용하기 때문에 실제 Query 요청이 느려질 수 있으므로 그때는 sort_buffer_size System Variable을 늘리는 것을 검토해야 합니다.📢 MySQL 8.0.12 이전의 경우 filesort 작업을 위한 메모리 할당 시 Optimizer가 고정된 메모리 공간을 할당받았으나, MySQL 8.0.12부터는 sort_buffer_size라는 System Variable에 설정된 사이즈까지 점진적으로 증가합니다. 이러한 변화는 소규모 정렬 작업에 과도한 메모리가 사용되는 상황을 피할 수 있으며, 대규모 정렬이 필요한 경우라면 필요에 따라 sort_buffer_size를 더 큰 값으로 설정할 수 있습니다.
📢 비슷한 개념으로, Oracle의 경우 할당된 메모리 공간만으로 정렬 작업이 가능한 경우를 Optimal Mode라고 부르지만, Temp 공간을 사용해야 하는 정렬 작업을 One-pass, Multi-pass라고 합니다. 특히 Multi-pass발생 시 Temp I/O 관련 Event가 관찰되며 성능 저하의 원인이 됩니다.
Join Buffer
조인 시 후행 테이블(Inner, Driven)의 조인 컬럼에 적절한 인덱스가 존재하지 않아 Index Scan, Index Range Scan 및 Full Table Scan을 수행해야 하는 경우 사용되는 영역입니다. (이 버퍼는 조인 유형이 ALL 또는 index 경우 사용합니다.)
Join Buffer는 Session 레벨에서 조인 단위로 생성되며, 필요한 만큼 할당되는 것이 아니라 Join Buffer가 필요한 시점에 모두 한꺼번에 할당받게 됩니다. 각 조인은 하나의 Join Buffer를 사용하므로 조인 타입이 ALL 또는 index인 테이블이 여러 개인 경우, 각각에 대해 버퍼를 할당하고 동일한 Row 조합을 여러 번 다른 버퍼에 저장합니다.
Join Buffer의 크기는
join_buffer_size 값에 따라 결정됩니다. Join Buffer의 크기가 크면 검색 횟수를 줄여 조인을 수행할 수 있습니다. 모든 조인에 대하여 설정한 크기만큼 최소 할당되므로 전역 설정값은 작게 유지하되, 대규모 조인을 수행하는 Session에서만 설정을 더 큰 값으로 변경하거나 SET_VAR Optimizer Hint를 사용하여 Query 별로 설정을 변경하는 것이 좋습니다.버퍼는 두 테이블을 Full Join 해야 할 때 하나의 Join Buffer가 할당되며, 인덱스가 사용되지 않는 여러 테이블을 복합 조인하는 경우에는 여러 개의 Join Buffer가 필요할 수 있습니다. 할당된 버퍼는 Query가 완료된 후 해제되며, 사용된 컬럼만 Join Buffer에 저장하고 전체 Row는 저장하지 않습니다.
Read Buffer
일반적으로 MyISAM 테이블에 대한 Sequential Scan(Full Table)을 수행해야 할 때, 각 테이블에 대해 Read Buffer를 할당합니다. 또한 MyISAM 엔진뿐만 아니라 기타 다른 엔진에서도 아래 언급한 경우에 대해서는 Read Buffer를 할당하여 사용합니다.
- 모든 스토리지 엔진에서 Read Buffer가 사용되는 경우는 다음과 같습니다.
- ORDER BY로 Row를 정렬할 때, 인덱스를 Temp File(Not Temp Table)에 캐시 하는 경우
- 파티션에 대량 Insert 하는 경우
- Nested Query의 결과를 캐싱하는 경우
Read Buffer의 크기는
read_buffer_size System Variable을 통해 설정할 수 있으며, Sequential Scan을 자주 수행하는 경우 이 값을 늘릴 수 있습니다. 다른 Local Memory와 마찬가지로, Client 별로 할당되므로 전역으로 큰 값으로 설정해서는 안되며 대용량 Query를 실행해야 하는 Client 내에서만 Session 단위로 변경하는 것이 좋습니다.📢 정렬 작업 이후에는 정렬된 순서대로 Data를 다시 읽을 때 디스크 탐색을 피하기 위하여 임시로 Read Buffer가 할당될 수 있습니다. 이때 사용되는 Read Buffer는 read_rnd_buffer_size System Variable에 의해 크기를 결정됩니다.
Connection Buffer & Result Buffer
Server는 Client Connection 요청에 대해 Thread를 생성하여 사용하는데, 이때 각 Thread에는 Connection Buffer와 Result Buffer라는 공간이 필요합니다.
두 버퍼 모두
net_buffer_length값만큼 초기 할당되며, 필요시 최대 max_allowed_packet 사이즈까지 확장됩니다. Query가 완료되면 Result Buffer는 net_buffer_length값으로 초기화되지만 Connection Buffer는 초기화되지 않습니다.Binlog Cache (Binlog=Binary Log)
Binary Log는 Replication 구성 또는 시점 복구 등에 사용하기 위한 로그이며, 테이블 생성 작업 또는 Data 변경과 같은 DB 변경사항 등 변화된 이벤트를 바이너리 방식으로 기록하고 있습니다. (Oracle의 Flashback 기능을 Binlog 기반으로 유사하게 구현할 수 있습니다.)
Binary Log 포맷은
STATEMENT, ROW, MIXED 세 가지로 지정할 수 있습니다.- STATEMENT (MySQL 5.7.6 이전 Default) : 실행한 Command(SQL)를 그대로 바이너리 로그에 작성하는 형식으로, 많은 Row를 업데이트하는 SQL에 대해서 효율적이며 공간을 많이 차지하지 않습니다. 그러나 SQL만 기록하기 때문에 일부 SQL에 함수가 포함된 경우 일관성 없는 실행 결과가 발생할 수 있습니다.
- ROW (MySQL 5.7.6 이후 Default) : 테이블의 Row가 어떻게 영향을 받는지 나타내는 이벤트를 작성(SQL 그대로가 아니고 SQL 수행에 따른 변경된 Data 기반)하는 방식입니다. 업데이트된 Row의 내용을 명확하게 기록하므로 Data가 정상적으로 복사되지 않는 상황이 발생하지 않습니다. Row에 영향을 주지 않는 Command를 실행하는 경우에 효율적입니다. (배치 업데이트, 전체 테이블 삭제, 테이블 변경 등의 작업의 경우에는 로그 양이 너무 많아 IO 성능 문제도 발생할 수 있습니다.)
- MIXED : STATEMENT+ROW, 기본적으로 STATEMENT 방식을 따르나 필요한 경우 ROW 방식으로 기록합니다.
MySQL Server는 이러한 Binary Log의 내용을 바로 디스크에 쓰지 않고 메모리의 임시 공간을 활용하여 버퍼링 하며, 이 공간을 Binlog Cache라고 합니다.
트랜잭션이 시작될 때 Thread는
binlog_cache_size라는 System Variable에 설정된 만큼 메모리를 미리 확보하여 트랜잭션 종료 시점까지 해당 메모리 영역에 트랜잭션을 기록합니다. 트랜잭션이 종료되면 바이너리 로그 파일에 해당 트랜잭션을 기록합니다.Status Variable 중에서
binlog_cache_use는 Binlog Cache 사용한 트랜잭션의 수를 나타내며, binlog_cache_disk_use는 Binlog Cache를 디스크(임시 파일)로 사용한 트랜잭션의 수를 나타냅니다. binlog_cache_use 대비하여 binlog_cache_disk_use 비율이 높다면 binlog_cache_size를 초과하는 트랜잭션의 수가 많음을 알 수 있습니다.그리고 트랜잭션을 캐시 하는 데 사용되는 총사이즈를
max_binlog_cache_size라는 System Variable로 제한하기 때문에, 이 값보다 큰 트랜잭션을 수행하면 다음과 같은 에러를 발생시키며 트랜잭션이 실패합니다.Multi-statement transaction required more than 'max_binlog_cache_size'bytes of storage
📢 비 트랜잭션에 대한 캐시는 binlog_stmt_cache_size로 크기를 할당된 공간을 사용하며 상태는 binlog_stmt_cache_use(바이너리 로그 캐시를 사용한 비 트랜잭션 수), binlog_stmt_cache_disk_use(바이너리 로그 캐시를 사용했지만 binlog_stmt_cache_size 설정값을 초과하여 임시 파일을 사용한 비 트랜잭션의 수)를 통해 확인합니다.
관련 파라미터
Parameter | Default Value | Range | Description |
key_buffer_size | 8388608 | 0 ~ OS_PER_PROCESS_LIMIT | • MyISAM 테이블의 인덱스 블록은 버퍼링되고 모든 Thread에서 공유되며, 이 인덱스 블록에 사용되는 Buffer(Key Cache)의 크기를 설정합니다.
• 모든 Read 및 다중 Write에 대한 인덱스 처리를 개선하기 위해 값을 늘릴 수 있습니다.
• 값이 너무 크면 Page를 작성을 시작하면 시스템의 속도가 매우 느려질 수 있습니다. (MySQL은 Data를 읽을때 파일 시스템 캐싱을 수행하기 위해 운영체제에 의존합니다.) |
table_open_cache | 4000 | 1 ~ 524288 | • 모든 Thread에 대하여 열려 있는 테이블 수를 제한합니다.• 이 값을 늘리면 mysqld에 필요한 File Descriptor 수가 증가합니다. |
max_connections | 151 | 1 ~ 100000 | 허용 가능한 최대 동시 Client Connection 수입니다. |
sort_buffer_size | 262144(256KB) | 32768 ~ [4GB-1](window 4294967295, other 18446744073709551615) | • 정렬을 수행해야 하는 각 Session에 할당되는 Buffer의 크기를 나타냅니다.
• Query 최적화 또는인덱스 개선으로 ORDER BY/GROUP BY 처리 속도를 개선할 수 없는 경우, 이 값을 늘리는 것을 고려합니다.
• 공간이 많이 필요한 Session에 대해서만 Session 설정으로 늘리는 것이 좋습니다. |
join_buffer_size | 262144(256KB) | 128 ~ [4GB-1](window 4294967295, other 18446744073709551615) | • 일반 Index Scans, Range Index Scans, 인덱스를 사용하지 않아 Full Table Scans을 하는 조인에 사용되는 Buffer의 크기를 나타냅니다.
• 인덱스를 추가할 수 없는 경우, 이 값을 늘리면 전체 조인 속도가 개선됩니다.
• 두 테이블 간의 전체 조인에 대해 하나의 Join Buffer가 할당되며, 여러 테이블 간의 복잡한 조인의 경우 Join Buffer가 여러개 필요할 수 있습니다.
• Global 설정은 작게 유지하고 큰 조인을 수행하는 Session에서만 Session 설정을 더 큰 값으로 변경하거나 Optimizer Hint를 사용하여 Query 별로 설정하는 것이 좋습니다. |
read_buffer_size | 131072(128KB) | 8192 ~ 2147479552 | MyISAM 테이블을 Sequential Scan하는 각 Thread는 검색하는 각 테이블에 대하여 Read Buffer를 할당하는데, 이 Buffer의 크기를 결정하는 System Variable입니다. |
read_rnd_buffer_size | 262144(256KB) | 1~ 2147483647 | • 모든 스토리지 엔진의 MRR(Multi-Range Read) 최적화에 사용되는 Random-read Buffer의 크기를 결정합니다.
• Secondary Index에서 Range Scan을 사용하여 Row를 읽으면, 테이블이 크고 InnoDB의 Cache에 저장되지 않은 경우 기본 테이블에 대한 많은 랜덤 디스크 Acccess가 발생할 수 있습니다. |
net_buffer_length | 16384 | 1024 ~ 1048576(1MB) | • 각 Client의 Thread는 이 값에 설정된 크기로 Connection Buffer, Result Buffer와 연결됩니다.• 필요에 따라 max_allowed_packet에 설정된 크기로 커지고 각 SQL 문 후에 Result Buffer는 이 값으로 다시 줄어듭니다. SQL문의 길이가 이 값을 초과하면 Connection Buffer가 자동으로 확대됩니다. |
max_allowed_packet | 67108864(64MB) | 1024 ~ 1073741824(1GB) | • 하나의 패킷이나 생성된/중간의 문자열의 최대 크기 또는 mysql_stmt_send_long_data() C API 함수에서 보낸 파라미터 등을 가리킵니다.
• Packet Message Buffer는 net_buffer_length로 초기화되지만 필요에 따라 max_allowed_packet로 증가할 수 있습니다.
• 큰 BLOB 컬럼이나 긴 문자열을 사용하는 경우에는 이 값을 늘려야 합니다. |
binlog_cache_size | 32768 | 4096 ~ 18446744073709547520(16EiB) | • 트랜잭션 중에 Binary Log에 대한 변경 내용을 저장할 Memory Buffer의 크기를 지정합니다.
• Binary Log가 활성화된 경우, 각 Client에 Binlog Cache가 할당되며, 각 트랜잭션이 Commit되면 Memory Buffer를 지우고 임시파일을 Truncate 함으로써 Binlog Cache가 재설정됩니다. |
max_binlog_cache_size | 18446744073709547520 | 4096 ~ 18446744073709547520(16EiB) | • Multi-statement 트랜잭션을 캐시하는데 사용되는 총 크기를 제한합니다.
• 트랜잭션이 설정한 값보다 크면 해당 트랜잭션은 실패하고 Rollback됩니다.• 권장 최대값은 4GB입니다. |
binlog_stmt_cache_size | 32768 | 4096 ~ 18446744073709547520(16EiB) | • 트랜잭션 중에 발생된 비트랜잭션문을 저장하는 Binary Log의 Memory Buffer 크기를 나타냅니다.
• 트랜잭션 중에 큰 비트랜잭션문을 자주 사용하는 경우, 이 값을 늘려 임시 파일에 쓰는 일을 줄이거나 제거하여 성능을 높일 수 있습니다. |
함께 보면 좋은 아티클
