MySQL 의 Query Cache 원리 분석

원리 QueryCache(이하 QC 로 약칭)는 SQL 문장 에 따라 cache 된다.SQL 조회 가 select 로 시작 하면 MySQL 서버 는 QC 를 사용 하려 고 시도 합 니 다.모든 Cache 는 SQL 텍스트 를 key 로 저장 합 니 다.QC 를 사용 하기 전에 SQL 텍스트 는 처리 되 지 않 습 니 다.즉,두 SQL 문 구 는 한 글자 라 도 차이 가 나 면(예 를 들 어 대소 문자 가 다 르 면)빈 칸 이 하나 더 있 는 등)이 두 SQL 은 다른 CACHE 를 사용 합 니 다.그러나 SQL 텍스트 는 클 라 이언 트 에 의 해 처 리 될 수 있 습 니 다.예 를 들 어 공식 명령 행 클 라 이언 트 에서 SQL 을 서버 에 보 내기 전에 다음 과 같이 처리 합 니 다.  모든 설명 필터  SQL 텍스트 앞 뒤의 빈 칸,TAB 등의 문 자 를 삭제 합 니 다.주의 하 세 요.텍스트 앞 과 뒤의 것 입 니 다.중간 거 안 빠 져 요.  다음 세 개의 SQL 에 서 는 SELECT 대소 문자 때문에 마지막 하 나 는 다른 두 개 와 QC 에서 다른 저장 위 치 를 사용 할 것 입 니 다.첫 번 째 조 와 두 번 째 조 는 후자 에 주석 이 있 고 서로 다른 클 라 이언 트 에서 서로 다른 결 과 를 얻 을 수 있다 는 것 과 구별 된다.따라서 안전 을 위해 동태 적 인 주석 을 사용 하지 마 십시오.PHP 의 my sql 확장 에 서 는 SQL 주석 이 지 워 지지 않 습 니 다.즉,세 개의 SQL 은 세 개의 서로 다른 캐 시 에 저 장 됩 니 다.비록 그들의 결 과 는 모두 같 지만.  select * FROM people where name='surfchen';  select * FROM people where /*hey~*/name='surfchen';  SELECT * FROM people where name='surfchen';  현재 selection 문 구 는 cache 에 만 있 고,다른 show 와 유사 한 문 구 는 cache 에 의 해 사용 되 지 않 습 니 다.QC 가 이렇게 전단 이 고 이렇게 간단 한 캐 시 시스템 이기 때문에 하나의 표 가 업데이트 되면 이 표 와 관련 된 SQL 의 모든 QC 가 효력 을 잃 게 됩 니 다.하나의 공동 조회 에 표 A 와 표 B 가 포함 되 어 있다 고 가정 하면 표 A 나 표 B 중 하나 가 업데이트(update 또는 delete)되면 이 조회 의 QC 는 효력 을 잃 게 됩 니 다.한 표 가 자주 업데이트 되면 관련 SQL 에 대해 QC 를 해 야 하 는 지 를 고려 해 야 한 다 는 것 이다.자주 업데이트 되 는 표 가 QC 에 적용 되면 부담 을 줄 이 는 것 이 아니 라 데이터베이스 에 부담 을 줄 일 수 있다.제 일반적인 방법 은 기본적으로 QC 를 열 고 자주 업데이트 되 는 표 와 관련 된 SQL 문 구 를 SQL 로 추가 하 는 것 입 니 다.NO_CACHE 키 워드 는 CACHE 를 사용 하지 않 습 니 다.이렇게 하면 가능 한 한 불필요 한 메모리 조작 을 피하 고 가능 한 한 메모리 의 연속 성 을 유지 할 수 있다.쿼 리 가 분 산 된 SQL 문장 도 QC 를 사용 해 서 는 안 된다.예 를 들 어 사용자 와 비밀 번 호 를 조회 하 는 문구-"select" pass from user where name='surfchen'”。이러한 문 구 는 한 시스템 에서 한 사용자 가 로그 인 할 때 만 사 용 될 가능성 이 높다.모든 사용자 의 로그 인 에 사용 되 는 조 회 는 서로 다른 SQL 텍스트 입 니 다.QC 는 여기 서 거의 작 동 하지 않 습 니 다.캐 시 된 데 이 터 는 거의 사용 되 지 않 고 메모리 에서 만 자 리 를 차지 하기 때 문 입 니 다.메모리 블록 은 이 섹 션 에서'메모리 블록'과'블록'이 같은 뜻 입 니 다.QC 캐 시가 하나의 검색 결 과 를 캐 시 할 때 보통 한 번 에 충분 한 메모 리 를 할당 하여 결 과 를 캐 시 하 는 것 이 아 닙 니 다.검색 결 과 를 얻 는 과정 에서 블록 별로 저장 하 는 것 이다.메모리 블록 이 채 워 지면 새 메모리 블록 이 생 성 되 고 메모리(allocate)가 분 배 됩 니 다.단일 메모리 블록 의 메모리 할당 크기 는 querycache_min_res_유닛 매개 변수 제어,기본 값 은 4KB 입 니 다.마지막 메모리 블록 은 모두 이용 되 지 않 으 면 사용 하지 않 은 메모리 가 방출 됩 니 다.캐 시 된 결과 가 많 으 면 메모리 할당 작업 이 너무 잦 아 지고 시스템 시스템 시스템 도 떨 어 질 수 있 습 니 다.캐 시 된 결과 가 작 으 면 메모리 조각 이 너무 많 을 수 있 습 니 다.이 조각 들 이 너무 작 으 면 더 이상 할당 되 지 않 을 수도 있 습 니 다.조회 결 과 를 제외 하고 모든 SQL 텍스트 도 하나의 저장 블록 이 필요 하 며 관련 된 표 도 하나의 저장 블록 이 필요 합 니 다(표 의 저장 블록 은 모든 스 레 드 가 공유 하고 표 마다 하나의 저장 블록 만 필요 합 니 다).메모리 블록 총 수량=조회 결과 수량*2+관련 데이터베이스 테이블 수량.즉,첫 번 째 캐 시가 생 성 될 때 적어도 세 개의 저장 블록 이 필요 하 다.표 정보 저장 블록,SQL 텍스트 저장 블록,조회 결과 저장 블록 이다.두 번 째 조 회 는 같은 표를 사용한다 면 최소한 두 개의 저장 블록 만 필요 합 니 다.SQL 텍스트 저장 블록,조회 결과 저장 블록 입 니 다.Qcache 관찰 을 통 해queries_in_cache 와 Qcachetotal_Blocks 는 모든 캐 시 결과 가 사용 하 는 메모리 블록 을 알 수 있 습 니 다.그것들의 비율 이 1:2 에 가깝다 면 현재 의 query 를 설명 한다cache_min_res_유닛 매개 변 수 는 이미 충분 합 니 다.하면,만약,만약...total_blocks 비 Qcachequeries_in_cache 가 많 으 면 query 를 증가 시 켜 야 합 니 다.cache_min_res_유닛 크기.Qcache_queries_in_cache*query_cache_min_res_유닛(sql 텍스트 와 표 정보 가 있 는 block 이 사용 하 는 메모리 가 작 습 니 다.무시 할 수 있 습 니 다)query 보다 훨씬 크 면cache_size-Qcache_free_memory,그럼 query 를 줄 여 볼 수 있 습 니 다.cache_min_res_유닛 값.크기 조정 Qcachelowmem_prunes 가 빠르게 증가 하 는 것 은 관련 표 가 업데이트 되 는 것 이 아니 라 메모리 가 부족 해서 많은 캐 시 를 방출 하 는 것 을 의미한다.query 확대 시도cache_size,가능 한 한 Qcachelowmem_prunes 제로 성장.  시작 매개 변수 show variables like 'query_cache%'에서 이 정 보 를 볼 수 있 습 니 다.query_cache_limit:단일 조회 결과 가 이 값 보다 크 면 Cache 하지 않 습 니 다.  query_cache_size:QC 에 분 배 된 메모리.0 으로 설정 하면 QC 를 비활성화 하 는 셈 이다.QC 는 40KB 정도 의 구 조 를 저장 해 야 하 며,40KB 이하 로 설정 하면 QC 를 사용 하지 않 는 것 과 같 습 니 다.QC 저장 소의 최소 단 위 는 1024 이다. byte,따라서 1024 배수 가 아 닌 값 을 설정 하면 이 값 은 현재 값 에 가장 가 까 운 1024 배수 값 으로 반올림 됩 니 다.  query_cache_type:0 QC 를 완전히 금지 합 니 다.SQL 구문 에 의 해 제어 되 지 않 습 니 다.(또한 주의해 야 할 것 은 여기 서 사용 하지 않 더 라 도 위의 매개 변수 가 설정 한 메모리 크기 는 분 배 됩 니 다)1.QC 를 사용 하면 SQL 구문 에서 SQL 을 사용 할 수 있 습 니 다.NO_CACHE 비활성화;2 SQL 문장 에 SQL 사용 가능CACHE 활성화.  query_cache_min_res_unit:매번 QC 결과 에 메모리 크기 를 할당 합 니 다.  상태 표시 status like 'Qcache%'에서 이 정 보 를 볼 수 있 습 니 다.Qcache_free_blocks:시계 가 업 데 이 트 된 후에 그것 과 관련 된 cache blocks 는 free 입 니 다.그러나 이 block 은 대기 열의 끝 에 있 지 않 는 한 대기 열 에 존재 할 수 있 습 니 다.이 blocks 들 은 이 값 으로 통 계 될 것 이다.FLUSH 로 할 수 있어 요. QUERY CACHE 문 구 를 비우 기 free blocks。  Qcache_free_memory:사용 가능 한 메모리,작 으 면 query 증가 고려cache_size  Qcache_hits:my sql 프로 세 스 시작 부터 cache 의 명중 수량  Qcache_inserts:mysql 프로 세 스 가 시 작 될 때 부터 QC 에 추 가 된 수량  Qcache_lowmem_prunes:메모리 가 너무 적어 서 QC 가 삭 제 된 항목 수 입 니 다.확대 querycache_size,가능 한 한 이 값 의 0 성장 을 유지 합 니 다.  Qcache_not_cached:my sql 프로 세 스 가 시 작 될 때 부터 cache 의 읽 기 전용 조회 수(select,show,use,desc 등 포함)가 없습니다.  Qcache_queries_in_cache:현재 cache 의 SQL 개수  Qcache_total_blocks:QC 에 있 는 blocks 수 입 니 다.하나의 query 는 여러 개의 blocks 에 저 장 될 수 있 으 며,이 몇 개의 blocks 중 마지막 으로 채 워 지지 않 은 메모리 가 방출 됩 니 다.예 를 들 어 QC 결 과 는 6KB 메모 리 를 차지 해 야 합 니 다.querycache_min_res_유닛 은 4KB 입 니 다.마지막 으로 3 개의 Blocks 를 생 성 합 니 다.첫 번 째 block 은 sql 문 구 를 저장 하 는 데 사 용 됩 니 다.이것 은 query+cache 로 통계 되 지 않 습 니 다.size 에 서 는 두 번 째 block 이 4KB,세 번 째 block 이 2KB(allocate4KB 를 먼저 사용 한 후 남 은 2KB 를 방출 함)입 니 다.표 마다 첫 번 째 SQL 조회 가 CACHE 에 있 을 때 하나의 block 을 사용 하여 표 정 보 를 저장 합 니 다.즉,block 은 표 정보,SQL 텍스트,조회 결과 세 곳 에 사 용 됩 니 다.