Loading...
MySQL 9.5 Reference Manual 9.5의 10.14.3 General Thread States의 한국어 번역본입니다.
아래의 경우에 피드백에서 신고해주신다면 반영하겠습니다.
감사합니다 :)
다음 목록은 일반적인 쿼리 처리와 관련되고 레플리케이션과 같은 보다 특수한 작업과는 관련되지 않은 스레드 State 값들을 설명합니다. 이들 중 많은 값은 서버의 버그를 찾는 데만 유용합니다.
After create이 상태는 스레드가 테이블(내부 임시 테이블 포함)을 생성하는 함수의 끝, 즉 테이블을 생성하는 함수가 끝날 때 발생합니다. 이 상태는 어떤 오류로 인해 테이블을 생성할 수 없었던 경우에도 사용됩니다.
altering table서버가 인플레이스 ALTER TABLE를 실행하는 중입니다.
Analyzing스레드가 MyISAM 테이블 키 분포를 계산하는 중입니다(예: ANALYZE TABLE의 경우).
checking permissions스레드가 서버에 해당 스테이트먼트를 실행할 수 있는 필요한 권한이 있는지 확인하는 중입니다.
Checking table스레드가 테이블 체크 작업을 수행하는 중입니다.
cleaning up스레드가 하나의 커맨드 처리를 완료했고, 메모리를 해제하고 특정 상태 변수를 리셋할 준비를 하는 중입니다.
closing tables스레드가 변경된 테이블 데이터를 디스크로 플러시하고 사용된 테이블들을 닫는 중입니다. 이 작업은 빠르게 끝나야 합니다. 그렇지 않다면, 디스크가 가득 차 있지 않은지, 디스크가 매우 고부하 상태가 아닌지 확인하십시오.
committing alter table to storage engine서버가 인플레이스 ALTER TABLE를 완료하고 그 결과를 커밋하는 중입니다.
converting HEAP to ondisk스레드가 내부 임시 테이블을 MEMORY 테이블에서 디스크 기반 테이블로 변환하는 중입니다.
copy to tmp table스레드가 ALTER TABLE 스테이트먼트를 처리하는 중입니다. 이 상태는 새로운 구조를 가진 테이블이 생성된 후, 행들이 그 테이블로 복사되기 전 사이에 발생합니다.
이 상태에 있는 스레드의 경우 Performance Schema를 사용하여 복사 작업의 진행 상황에 대한 정보를 얻을 수 있습니다. Section 29.12.5, “Performance Schema Stage Event Tables”를 참조하십시오.
Copying to group table스테이트먼트에 ORDER BY와 GROUP BY 기준이 다르게 지정된 경우, 행들이 그룹 기준으로 정렬되고 임시 테이블로 복사됩니다.
Copying to tmp table서버가 메모리상의 임시 테이블로 복사하는 중입니다.
Copying to tmp table on disk서버가 디스크상의 임시 테이블로 복사하는 중입니다. 임시 결과 집합이 너무 커졌습니다(Section 10.4.4, “Internal Temporary Table Use in MySQL” 참조). 따라서 스레드는 메모리를 절약하기 위해 임시 테이블을 인메모리 포맷에서 디스크 기반 포맷으로 변경하는 중입니다.
Creating index스레드가 MyISAM 테이블에 대해 ALTER TABLE ... ENABLE KEYS를 처리하는 중입니다.
Creating sort index스레드가 내부 임시 테이블을 사용하여 처리되는 SELECT를 처리하는 중입니다.
creating table스레드가 테이블을 생성하는 중입니다. 여기에는 임시 테이블 생성도 포함됩니다.
Creating tmp table스레드가 메모리 또는 디스크에 임시 테이블을 생성하는 중입니다. 테이블이 메모리에 생성되었다가 이후 디스크 기반 테이블로 변환되는 경우, 해당 작업 동안의 상태는 Copying to tmp table on disk입니다.
deleting from main table서버가 멀티테이블 삭제의 첫 번째 부분을 실행하는 중입니다. 첫 번째 테이블에서만 삭제를 수행하며, 다른(참조) 테이블에서 삭제하는 데 사용할 컬럼과 오프셋을 저장합니다.
deleting from reference tables서버가 멀티테이블 삭제의 두 번째 부분을 실행하고 있으며, 다른 테이블들에서 매칭된 행을 삭제하는 중입니다.
discard_or_import_tablespace스레드가 ALTER TABLE ... DISCARD TABLESPACE 또는 ALTER TABLE ... IMPORT TABLESPACE 스테이트먼트를 처리하는 중입니다.
end이 상태는 다음 스테이트먼트들의 정리(cleanup) 이전, 끝 부분에서 발생합니다:
ALTER TABLE,
CREATE VIEW,
DELETE,
INSERT,
SELECT,
UPDATE 스테이트먼트.
end 상태에서 다음 작업이 수행될 수 있습니다:
바이너리 로그에 이벤트를 기록
BLOB을 포함한 메모리 버퍼 해제
executing
스레드가 스테이트먼트 실행을 시작한 상태입니다.
Execution of init_command스레드가 init_command 시스템 변수 값에 지정된 스테이트먼트들을 실행하는 중입니다.
freeing items스레드가 커맨드를 실행 완료한 상태입니다. 일반적으로 이어서 cleaning up 상태가 됩니다.
FULLTEXT initialization서버가 자연어 풀텍스트 검색을 수행할 준비를 하는 중입니다.
init이 상태는 다음 스테이트먼트들의 초기화 이전에 발생합니다:
ALTER TABLE,
DELETE,
INSERT,
SELECT,
UPDATE 스테이트먼트. 이 상태에서 서버가 수행하는 작업에는 바이너리 로그와 InnoDB 로그 플러시가 포함됩니다.
Killed누군가가 스레드에 KILL 스테이트먼트를 보냈으며, 스레드는 킬 플래그를 다음에 확인할 때 중단해야 합니다. MySQL의 각 주요 루프에서 플래그를 확인하지만, 경우에 따라 스레드가 종료될 때까지 약간의 시간이 걸릴 수 있습니다. 스레드가 다른 스레드에 의해 잠겨 있는 경우, 킬은 다른 스레드가 락을 해제하는 즉시 효력이 발생합니다.
Locking system tables스레드가 시스템 테이블(예: 시간대 테이블 또는 로그 테이블)에 락을 걸려고 하는 중입니다.
logging slow query스레드가 스테이트먼트를 슬로우 쿼리 로그에 기록하는 중입니다.
login클라이언트가 인증에 성공할 때까지 커넥션 스레드의 초기 상태입니다.
manage keys서버가 테이블 인덱스를 활성화하거나 비활성화하는 중입니다.
Opening system tables스레드가 시스템 테이블(예: 시간대 테이블 또는 로그 테이블)을 열려고 하는 중입니다.
Opening tables스레드가 테이블을 열려고 하는 중입니다. 이 작업은 테이블 오픈을 방해하는 무언가가 없다면 매우 빨리 끝나야 합니다. 예를 들어, ALTER TABLE 또는 LOCK TABLE 스테이트먼트는 해당 스테이트먼트가 완료될 때까지 테이블 오픈을 막을 수 있습니다. 또한 table_open_cache 값이 충분히 큰지 확인하는 것이 좋습니다.
시스템 테이블의 경우에는 Opening system tables 상태가 대신 사용됩니다.
optimizing서버가 쿼리에 대한 초기 옵티마이제이션을 수행하는 중입니다.
preparing이 상태는 쿼리 옵티마이제이션 중에 발생합니다.
preparing for alter table서버가 인플레이스 ALTER TABLE 실행을 준비하는 중입니다.
Purging old relay logs스레드가 필요 없는 릴레이 로그 파일들을 제거하는 중입니다.
query end이 상태는 쿼리 처리를 완료한 후, freeing items 상태 이전에 발생합니다.
Receiving from client서버가 클라이언트로부터 패킷을 읽는 중입니다.
Removing duplicates쿼리는 MySQL이 초기 단계에서 디스트링트 작업을 최적화하여 제거할 수 없는 방식으로 SELECT DISTINCT를 사용했습니다. 이로 인해 MySQL은 결과를 클라이언트에 보내기 전에 모든 중복 행을 제거하는 추가 단계를 필요로 합니다.
removing tmp table스레드가 SELECT 스테이트먼트를 처리한 후 내부 임시 테이블을 제거하는 중입니다. 임시 테이블이 생성되지 않은 경우 이 상태는 사용되지 않습니다.
rename스레드가 테이블 이름을 변경하는 중입니다.
rename result table스레드가 ALTER TABLE 스테이트먼트를 처리하는 중이며, 새 테이블을 생성한 후 원래 테이블을 대체하기 위해 그 이름으로 이름을 변경하는 중입니다.
Reopen tables스레드가 테이블에 대한 락을 획득했지만, 락을 얻은 후 기본 테이블 구조가 변경되었음을 감지했습니다. 따라서 락을 해제하고 테이블을 닫은 뒤, 테이블을 다시 열려고 시도하는 중입니다.
Repair by sorting리페어 코드가 정렬을 사용하여 인덱스를 생성하는 중입니다.
Repair done스레드가 MyISAM 테이블에 대한 멀티스레드 리페어를 완료했습니다.
Repair with keycache리페어 코드가 키 캐시를 통해 키를 하나씩 생성하는 중입니다. 이는 Repair by sorting보다 훨씬 느립니다.
Rolling back스레드가 트랜잭션을 롤백하는 중입니다.
Saving state리페어나 분석과 같은 MyISAM 테이블 작업의 경우, 스레드가 새로운 테이블 상태를 .MYI 파일 헤더에 저장하는 중입니다. 이 상태에는 행 수, AUTO_INCREMENT 카운터, 키 분포 등의 정보가 포함됩니다.
Searching rows for update스레드가 업데이트를 수행하기 전에 일치하는 모든 행을 찾는 첫 번째 단계(페이즈)를 수행하는 중입니다. 이는 UPDATE가 관련 행을 찾는 데 사용되는 인덱스를 변경하는 경우에 필요합니다.
Sending data이 상태는 이제 Executing 상태에 포함됩니다.
Sending to client서버가 클라이언트로 패킷을 쓰는 중입니다.
setup스레드가 ALTER TABLE 작업을 시작하는 중입니다.
Sorting for group스레드가 GROUP BY를 충족하기 위해 정렬을 수행하는 중입니다.
Sorting for order스레드가 ORDER BY를 충족하기 위해 정렬을 수행하는 중입니다.
Sorting index스레드가 MyISAM 테이블 옵티마이제이션 작업 중에 더 효율적인 접근을 위해 인덱스 페이지를 정렬하는 중입니다.
Sorting resultSELECT 스테이트먼트의 경우, 이 상태는 비임시 테이블에 대해 Creating sort index와 유사한 작업을 나타냅니다.
starting스테이트먼트 실행의 시작 지점에서의 첫 번째 단계입니다.
statistics서버가 쿼리 실행 계획을 수립하기 위해 통계를 계산하는 중입니다. 스레드가 이 상태에 오랫동안 머문다면, 서버는 다른 작업으로 인해 디스크 바운드 상태일 가능성이 높습니다.
System lock스레드가 mysql_lock_tables()를 호출했고, 이후 스레드 상태가 아직 업데이트되지 않은 상태입니다. 이는 여러 가지 이유로 발생할 수 있는 매우 일반적인 상태입니다.
예를 들어, 스레드가 테이블에 대한 내부 또는 외부 시스템 락을 요청하려 하거나 기다리고 있을 수 있습니다. 이는 InnoDB가 LOCK TABLES 실행 중에 테이블 수준 락을 기다릴 때 발생할 수 있습니다. 이 상태가 외부 락 요청으로 인해 발생하고, 동일한 MyISAM 테이블에 접근하는 여러 mysqld 서버를 사용하지 않는다면, --skip-external-locking 옵션으로 외부 시스템 락을 비활성화할 수 있습니다. 그러나 외부 락은 기본적으로 비활성화되어 있으므로, 이 옵션은 효과가 없을 가능성이 큽니다. SHOW PROFILE의 경우 이 상태는 스레드가 락을 요청하고 있음을 의미합니다(기다리는 중이 아님).
시스템 테이블의 경우에는 Locking system tables 상태가 대신 사용됩니다.
update스레드가 테이블 업데이트를 시작할 준비를 하는 중입니다.
Updating스레드가 업데이트할 행을 검색하고 실제로 업데이트하는 중입니다.
updating main table서버가 멀티테이블 업데이트의 첫 번째 부분을 실행하는 중입니다. 첫 번째 테이블에서만 업데이트를 수행하며, 다른(참조) 테이블들을 업데이트하는 데 사용할 컬럼과 오프셋을 저장합니다.
updating reference tables서버가 멀티테이블 업데이트의 두 번째 부분을 실행하고 있으며, 다른 테이블들에서 매칭된 행을 업데이트하는 중입니다.
User lock스레드가 GET_LOCK() 호출로 요청된 어드바이저리 락을 요청하려 하거나 기다리는 중입니다. SHOW PROFILE의 경우 이 상태는 스레드가 락을 요청하고 있음을 의미합니다(기다리는 중이 아님).
User sleep스레드가 SLEEP() 호출을 수행한 상태입니다.
Waiting for commit lockFLUSH TABLES WITH READ LOCK이 커밋 락을 기다리는 중입니다.
waiting for handler commit스레드가 쿼리 처리의 다른 부분과 비교하여 트랜잭션 커밋을 기다리는 중입니다.
Waiting for tables스레드가 테이블의 기본 구조가 변경되었으며, 새로운 구조를 얻기 위해 테이블을 다시 열어야 한다는 통지를 받은 상태입니다. 그러나 테이블을 다시 열기 위해서는 다른 모든 스레드가 해당 테이블을 닫을 때까지 기다려야 합니다.
이러한 통지는 다른 스레드가 해당 테이블에 대해 FLUSH TABLES 또는 다음 스테이트먼트 중 하나를 사용했을 때 발생합니다:
FLUSH TABLES tbl_name,
ALTER TABLE,
RENAME TABLE,
REPAIR TABLE,
ANALYZE TABLE,
OPTIMIZE TABLE.
Waiting for table flush스레드가 FLUSH TABLES를 실행하고 있으며, 모든 스레드가 자신의 테이블을 닫기를 기다리는 중입니다. 또는 스레드가 테이블의 기본 구조가 변경되었으며 새로운 구조를 얻기 위해 테이블을 다시 열어야 한다는 통지를 받은 상태입니다. 그러나 테이블을 다시 열기 위해서는 다른 모든 스레드가 해당 테이블을 닫을 때까지 기다려야 합니다.
이러한 통지는 다른 스레드가 해당 테이블에 대해 FLUSH TABLES 또는 다음 스테이트먼트 중 하나를 사용했을 때 발생합니다:
FLUSH TABLES tbl_name,
ALTER TABLE,
RENAME TABLE,
REPAIR TABLE,
ANALYZE TABLE,
OPTIMIZE TABLE.
Waiting for lock_type lock서버가 THR_LOCK 락 또는 메타데이터 락킹 서브시스템의 락을 획득하기를 기다리는 중이며, 여기서 _lock_type_은 락의 유형을 나타냅니다.
이 상태는 THR_LOCK에 대한 대기를 나타냅니다:
Waiting for table level lock다음 상태들은 메타데이터 락에 대한 대기를 나타냅니다:
Waiting for event metadata lock
Waiting for global read lock
Waiting for schema metadata lock
Waiting for stored function metadata lock
Waiting for stored procedure metadata lock
Waiting for table metadata lock
Waiting for trigger metadata lock
테이블 락 인디케이터에 대한 정보는 Section 10.11.1, “Internal Locking Methods”를 참조하십시오. 메타데이터 락킹에 대한 정보는 Section 10.11.4, “Metadata Locking”을 참조하십시오. 어떤 락이 락 요청을 블록하고 있는지 확인하려면, Section 29.12.13, “Performance Schema Lock Tables”에 설명된 Performance Schema 락 테이블을 사용하십시오.
Waiting on cond스레드가 어떤 컨디션이 true가 되기를 기다리고 있는 일반적인 상태입니다. 특정한 상태 정보는 제공되지 않습니다.
Writing to net서버가 네트워크로 패킷을 쓰는 중입니다.
10.14.2 Thread Command Values
10.14.4 Replication Source Thread States