The Mysql website offers database software, services and support for your business, including the Enterprise server, the Network monitoring and advisory services and the production support. The wide range of products include: Mysql clusters, embedded database, drivers for JDBC, ODBC and Net, visual database tools (query browser, migration toolkit) and last but not least the MaxDB- the open source database certified for SAP/R3. The Mysql services are also made available for you. Choose among the Mysql training for database solutions, Mysql certification for the Developers and DBAs, Mysql consulting and support. It makes no difference if you are new in the database technology or a skilled developer of DBA, Mysql proposes services of all sorts for their customers.

Data Bases:

Current DB: web

Tables:

Database : mysql

Table:

# mysql.user Data

Databsae: web_control

Table:

Database: certification

Tables:

Database: wordpress

Tables:

Database: bk

Table:

• Query cache는 system-wide한 글로벌 메모리 공간
• Query cache는 Full scan등과 같이 큰 공간이 필요한 결과는 캐시하지 않도록 
  캐시 최대 사이즈를 제한(query_cache_limit)
• Query의 결과를 캐시하기 위해서 메모리의 공간을 할당 받을 때, 
  query_cache_min_res_unit 단위로 할당 받으며 (필요시 더 추가적으로), 
  캐시 작업이 완료된 이후 남은 미사용 공간은 반납하게 된다.
• Query cache는 테이블 단위로 Invalidate 되기 때문에, 
  테이블이 상당히 자주 변경된다면 cache의 효율이 떨어질 수 있다.
• 일반적으로는 Query cache의 매치 기준은 Query 문장이 동일한지(대소문자 및 공백까지) 비교하는 방식이며 InnoDB의 경우에는 레코드 기반의 락을 사용하며 MVCC의 제어가 필요하기 때문에 
  재사용 가능한지 판단은 Query 문장뿐만 아니라 Transaction Id로 레코드 접근성까지 비교해야 함
• Query cache의 관리 비용은 얻는 효과에 비하면 아주 미미하지만, 
  가끔은 캐시 내용을 invalidate 하는데 상당히 많은 비용이 필요할 수도 있음
• 일반적으로 Query cache는 아래의 경우 상당히 도움이 된다.
   - 테이블이 자주 변경되지 않는 경우
   - 쿼리의 실행 과정은 복잡하고 많은 처리가 필요하지만 결과 셋의 사이즈가 작은 경우
   - 동일 쿼리가 자주 실행되는 경우
• Query cache의 Hit-Ratio는 계산하는 MySQL의 Status 값 Key_reads를 Status값 Key_read_requests로 나누는 방법으로 계산하지만, 이 값이 90%면 좋고 20%면 나쁘다는 단순한 판단은 힘듬 
    -> Query cache의 효율성 판단은 실제 운영 시스템에서 활성화/비활성화를 비교해보는 것이 제일 좋을 듯 하지만, 운영 시스템이므로 주의가 필요
    -> query_cache_size 설정 변수는 전역이면서 동적 변수이기 때문에 실시간으로 변경이 가능하므로 서비스 영향 없이 설정 변경 후 비교 가능 
       (주의해야 할 것은 기존과 동일하든지 다른 값이든지 일단 한번 설정이 되면 지금까지의 캐시된 내용은 모두 제거됨)

• 1) 그림의 아래 부분 처럼 각 색깔별로 A,B,C,D,E 쿼리들이 실행되어서, 1) 번과 같은 상태의 Query cache가 있다고 가정해보자
  - 그림에서 하나의 영역은 Query cache block 으로 일반적으로 "query_cache_min_res_unit"로 정의된 사이즈이며, 
  - <1>번이라고 적힌 영역은 캐시될 ResultSet 을 저장하기 위해서 "query_cache_min_res_unit" 크기의 메모리 블럭을 할당 받아서 사용하다가 남는 공간은 다시 반납하게 되는데, 이 때문에 발생한 빈 공간임 (Fragmentation이라고도 하며, 이런 공간들은 쉽게 재활용되지 못함)
  - 뒷 부분의 흰색 블럭들은 아직 미사용된 블럭들을 표시함 
• 2) 이 상태에서 아래와 같이 tab2와 tab4를 변경하는 쿼리가 실행되면, 해당 테이블을 참조하는 모든 Query cache는 모두 제거됨
  - UPDATE tab2 SET ... WHERE ...
  - UPDATE tab4 SET ... WHERE ... 
  이런 공간들은 주위의 미사용 영역들과 병합되어서, 나중에 재활용될 수 있음 
  (이런 공간들도 모두 일반적으로 Fragmentation 이라고 표현함) 
• 3) 아래 명령을 이용하여 이렇게 발생한 Query cache의 Fragmentation을 제거하고, 
  미 사용 영역을 모두 연속된 공간으로 만들어줄 수 있음
  - FLUSH QUERY CACHE;
  이 명령은 Query cache 전체에 대해서 변경되지 않도록 락을 걸기 때문에 조심해서 실행해야 함 
• 이러한 Query cache 의 block 할당에 관련된 정보는 MySQL의 상태값으로 확인 가능함
  - Qcache_total_blocks   : 무조건 할당된 공간까지의 모든 block들(사용중이든 아니든)의 수를 보여줌
  - Qcache_free_blocks    : 미사용 block들 (Fragmentation이라고 표현한 영역들)의 수를 보여줌
  - 1)번 그림 : Qcache_total_blocks -> 16,  Qcache_free_blocks -> 2
  - 2)번 그림 : Qcache_total_blocks -> 16,  Qcache_free_blocks -> 3
  - 3)번 그림 : Qcache_total_blocks -> 11,  Qcache_free_blocks -> 1

• 아래와 같은 형태로 실행되는 쿼리는 Query cache를 사용하지 못함
  - PreparedStatement로 실행되는 쿼리 (MySQL 5.1.17 이후 부터는 Query cache를 사용 가능)
  - Stored Procedure, Function, Trigger 내부에서 실행되는 쿼리
  - Sub Query 형태로 실행되는 쿼리

• query_cache_limit 
  이 값으로 설정된 사이즈 이상의 결과 셋을 가지는 경우에는 Query cache에 캐시하지 않도록 설정
• query_cache_min_res_unit 
  Query cache에서 결과 셋을 캐시하기 위한 메모리 공간을 할당 받을 때 사용하는 메모리 할당 최소 단위 사이즈
• query_cache_size 
  Query cache의 전체 사이즈를 설정하며 1024Byte의 배수로 설정, 
  Query cache를 완전히 비활성화하기 위해서는 이 변수의 값을 0으로 설정해야 한다.
• query_cache_type 
  Query 의 결과 셋을 어떻게 저장할지를 결정함, 
  - OFF는 캐시하지 않음, 
  - ON은 SQL_NO_CACHE 힌트가 없는 SELECT 문장의 결과 셋은 캐시 대상으로 가정, 
  - DEMAND 는 SQL_CACHE 힌트가 SELECT 문장에 있는 결과 셋만 캐시 대상으로 가정
• query_cache_wlock_invalidate 
  어떤 Client가 MyISAM 테이블에 Write lock을 가지고 있는 경우, 
  다른 Client가 Query cache에서 결과를 가져갈 수 있는 SELECT문장을 실행하는 것은 Block되지 않는데, 이 값을 TRUE로 설정하면 결과를 Query cache에서 가져갈 수 있다 하더라도, 다른 Client는 대기해야 하도록 만든다.