MySQL 쿼리 캐싱을 비활성화하는 방법

MySQL 쿼리 캐싱을 비활성화하는 방법

다른 열에 대한 다른 쿼리를 벤치마킹하려고 하는데 MySQL에서 이를 허용하지 않습니다.쿼리를 처음 실행한 후에는 해당 쿼리에 대해 동일한 실행 시간을 다시 얻을 수 없습니다.예를 들어 쿼리가 처음 0.062초 안에 실행되면 두 번째, 세 번째 등 실행에 대해 동일한 실행 시간을 절대 얻을 수 없습니다.0초나 0.015 정도가 됩니다.

MySQL 쿼리 캐시 비활성화 및 삭제에 대한 게시물을 많이 읽었지만 그 중 어떤 것도 도움이 되지 않았습니다.

이 SO 게시물을 여기에.

제가 어떻게 하든 MySQL은 캐시된 결과를 사용해야 한다고 고집하는 것 같습니다.

MySQL Workbench를 다시 시작한 다음 실행합니다.

set global query_cache_type=0;
set global query_cache_size=0;
flush query cache;
reset query cache;

실행 시간이 계속 0초로 표시됩니다.

아직 변경하지 못한 서버 변수는 have_query_cache뿐입니다.값은 "예"이며 "아니오"로 설정하려고 하면 워크벤치에 읽기 전용이라고 표시됩니다.

저도 그렇습니다.

set profiling=1;
run my select query
show profile for query 2;

프로파일링 결과는 다음과 같습니다.

'starting', '0.000077'
'checking permissions', '0.000007'
'Opening tables', '0.000016'
'init', '0.000035'
'System lock', '0.000009'
'optimizing', '0.000013'
'statistics', '0.000094'
'preparing', '0.000008'
'executing', '0.000002'
'Sending data', '0.000016'
'end', '0.000002'
'query end', '0.000003'
'closing tables', '0.000005'
'freeing items', '0.000139'
'cleaning up', '0.000009'

제가 틀리지 않았다면 캐시가 사용되고 있지 않다는 것을 알 수 있습니다.그래도 0초는 보여요.사형집행을 위하여

편집: 현재 실행 중인 쿼리는 다음과 같이 "SQL_NO_CACHE"를 사용하는 SELECT 쿼리입니다.

SELECT SQL_NO_CACHE col1,now() from mytable where col2="some_value"

(쿼리 캐싱 방지를 위해 now() 함수를 추가했습니다.

편집2: innoDB, MySQL 5.6.10을 사용하고 있습니다.

제가 여기서 무슨 일이 일어나고 있는지 안 보이는데 누가 좀 도와주실 수 있나요.

정말 고마워.

이는 쿼리 캐시가 아닌 데이터 자체의 캐시 때문일 수 있습니다.

SELECT 문 뒤에 SQL_NO_CACHE를 추가하여 단일 문에 대한 쿼리 캐시를 비활성화할 수 있습니다.

예:

SELECT SQL_NO_CACHE field FROM table.

하면 됩니다가 .InnoDB버퍼 풀을 테이블의 관련 블록으로 채웁니다.

쿼리를 다시 실행하려면 정확히 동일한 블록이 필요하므로 쿼리를 다시 실행할 때 디스크에서 읽을 필요가 없으므로 쿼리를 훨씬 더 빨리 실행할 수 있습니다.

버퍼 풀 페이지 읽기와 페이지를 가져오기 위해 디스크로 이동해야 했던 페이지 읽기의 차이를 확인할 수 있습니다.

mysql> SHOW SESSION STATUS LIKE 'Innodb_buffer_pool_read%';
mysql> ...run a query...
mysql> SHOW SESSION STATUS LIKE 'Innodb_buffer_pool_read%';

보고서에서 이 값들을 비교하고, 이 값들이 얼마나 성장하는지 기록합니다.

+---------------------------------------+----------+
| Variable_name                         | Value    |
+---------------------------------------+----------+
| Innodb_buffer_pool_read_requests      | 10327490 |
| Innodb_buffer_pool_reads              | 1133     |
+---------------------------------------+----------+

read_requests는 논리 페이지 읽기로, 버퍼 풀에 이미 있는 페이지에서 읽을 수 있습니다.쿼리 후에 이 숫자가 증가하지만 읽기는 증가하지 않으면 쿼리는 버퍼 풀에서만 결과를 가져옵니다.

읽기 수는 페이지를 버퍼 풀에 복사하는 데 필요한 I/O 비용을 발생시키고 Disk로 이동해야 했던 페이지 읽기 수입니다.쿼리 후에 이 숫자가 증가하면 디스크에서 데이터를 로드해야 합니다.

메모리 액세스 성능과 디스크 액세스 성능의 차이에 대한 자세한 내용은 http://everythingisdata.wordpress.com/2009/10/17/numbers-everyone-should-know/ 을 참조하십시오.

---

의견 다시 작성:

"오프닝 테이블"은 데이터 사전과 같은 InnoDB 테이블의 인메모리 캐시와 관련이 있습니다.테이블은 재시작 후 처음 참조될 때 열립니다.인메모리 데이터 사전의 특정 테이블의 항목은 메모리에 무한히 남아 있기 때문에 수천 개의 테이블이 있을 경우 메모리 사용량이 상당히 증가할 수 있습니다.MySQL 5.6에서는 메모리 사용량을 제한하고 자주 사용하지 않는 테이블을 제거하기 위한 몇 가지 조정 변수가 있습니다.그러나 이 전체 메커니즘은 데이터 및 인덱스 페이지를 저장하는 버퍼 풀과는 별개입니다.

또한 "통계"는 버퍼 풀과는 별개입니다.InnoDB는 데이터 및 인덱스에 대한 인메모리 통계를 유지하며, 이를 통해 쿼리 최적화기를 안내합니다.InnoDB 테이블에 처음 액세스할 때, SHOW TABLE STATUS를 실행하거나 INFORMATION_SCHEMA에 대해 특정 쿼리를 실행할 때, ANALIGHTLE TABLE을 실행할 때, 테이블 크기가 크게 변경될 때도 통계가 자동으로 새로 고쳐집니다.InnoDB는 테이블에서 고정된 페이지 수를 랜덤하게 읽는 이러한 통계를 생성하며, 콜드 버퍼 풀이 있는 경우 디스크에 영향을 줄 가능성이 있습니다.

좋아요 그래서 이 innoDB 버퍼 풀 문제에 대해 계속 생각해왔습니다@Quassnoi, @TheVedge에 대해 언급해 주셔서 감사합니다.그것은 다음 작업에 매우 유용했습니다.

innoDB 버퍼 풀을 비활성화하거나 재설정하는 방법을 찾으려고 했는데 MySQL 서버를 재시작하는 방법 외에 다른 방법을 찾을 수 없습니다. (윈도우 박스에서 서버를 재시작하려면 services.msc 또는 명령 프롬프트를 사용할 수 있습니다.)

모든 구성 변수 설정과 "SQL_NO_CACHE" 사용은 캐시 사용을 피하기에 충분했고 프로파일링 결과를 확인하는 것도 캐시 참조를 보지 못했습니다(원 게시물 확인).

그리고 MySQL 서버를 다시 시작한 후 동일한 쿼리의 1차 실행과 2차 실행에 대한 프로파일링을 확인하기로 했습니다.이렇게 하면 쿼리 실행 중에 어떤 일이 있었는지 단계적으로 확인할 수 있습니다.

서버 재시작 후 첫 번째 실행에서는 다음 단계와 타이밍이 산출되었습니다.

'starting', '0.000078'
'checking permissions', '0.000005'
'Opening tables', '0.120329'
'init', '0.000107'
'System lock', '0.000012'
'optimizing', '0.000024'
'statistics', '0.065317'
'preparing', '0.000026'
'executing', '0.000003'
'Sending data', '0.000038'
'end', '0.000005'
'query end', '0.000006'
'closing tables', '0.000014'
'freeing items', '0.000463'
'cleaning up', '0.000039'

그리고 2차 주행의 결과는 다음과 같습니다.

'starting', '0.000068'
'checking permissions', '0.000006'
'Opening tables', '0.000019'
'init', '0.000046'
'System lock', '0.000007'
'optimizing', '0.000010'
'statistics', '0.000073'
'preparing', '0.000009'
'executing', '0.000002'
'Sending data', '0.000035'
'end', '0.000003'
'query end', '0.000003'
'closing tables', '0.000006'
'freeing items', '0.000181'
'cleaning up', '0.000015'

두 실행 사이의 "열기 테이블" 및 "통계" 작업의 기간에는 큰 차이가 있으며, 어떤 실행도 캐시를 참조하지 않습니다.

이 두 가지 작업은 첫 번째 실행에 가장 많은 시간이 소요되는 부분인 것 같습니다(innoDB 버퍼 풀 생성의 일부로 생각됩니다). 풀이 생성되면 버퍼 풀 생성 후 쿼리의 실행 시간이 크게 단축됩니다.

두 번째 실행에 대한 개별 단계의 실행 시간을 합하면 0.000483초를 얻을 수 있으며 MySQL 워크벤치는 이 결과를 0.000초로 보여주며, 두 번째 실행이 캐시 사용의 결과라고 생각하는 것처럼 속일 수도 있지만 실제로는 그렇지 않은 것 같습니다.이는 쿼리 실행 기간에 대한 표시 정밀도 문제일 뿐입니다.

결과적으로 지금까지 알게 된 것은 실제로 캐시 사용을 비활성화할 수 있었고 두 번째 쿼리의 속도를 매우 빠르게 하는 것이 innoDB 버퍼 풀의 완성이라는 것입니다.이것은 또한 0.000483초 만에 200만 행의 기록을 찾을 수 있다는 것을 의미합니다.

동의하십니까?

[mysqld] 섹션의 .ini/.cfg에 선을 추가합니다.have_query_cache=0 # to prevent using resources from default of yes ccyy/mm/dd your initials. 다른 변경 사항을 사용하여 MySQL을 닫거나 다시 시작합니다.프로파일 조사에서 QC 활동을 관찰해서는 안 됩니다.

언급URL : https://stackoverflow.com/questions/16043943/how-to-disable-mysql-query-caching