MySQL에서 쿼리 캐시를 해제해야 합니까?

MySQL에서 쿼리 캐시를 해제해야 합니까?

32GB RAM을 탑재한 전용 서버와 Maria DB 10.1을 사용하는 8코어 서버를 사용하고 있으며 대부분의 테이블은 InnoDB입니다.전체 DB 사이즈는 2GB 미만이지만 성능이 느린 것 같습니다.

이하에 나타냅니다.my.cnf사용 중인 파일:

[mysqld]
log-error=/home/MySQL_Server/mysql/dedi.server.co.err
datadir=/home/MySQL_Server/mysql
pid-file=/home/MySQL_Server/mysqlmysqld.pid
innodb_file_per_table=1

skip-name-resolve=1
bind-address=127.0.0.1
#skip-networking=1
#query_cache_type=0
query_cache_type=1
innodb_file_per_table=1
default-storage-engine=InnoDB

#query_cache_size=0
query_cache_size=128M
query_cache_limit=256K
query_cache_min_res_unit = 2k

performance_schema=ON
innodb_buffer_pool_size = 1536M
innodb_log_file_size = 140M
innodb_log_files_in_group=2

sort_buffer_size=256k
join_buffer_size=256k
read_buffer_size=256k
read_rnd_buffer_size=256k
thread_stack=256k
mrr_buffer_size=256k

join_cache_level=8

tmp_table_size=64M
max_heap_table_size=64M

table_open_cache=1024
thread_cache_size=32

innodb_buffer_pool_instances=1

innodb_use_sys_malloc = 1

max_connections=500
wait_timeout=300
interactive_timeout=360
#tmpdir=/var/mysqltmp
#max_allowed_packet=268435456

MySQL Tuner는 다음을 제안했습니다.

General recommendations:
    Control warning line(s) into /home/MySQL_Server/mysql/dedi.niresh.co.err file
    Control error line(s) into /home/MySQL_Server/mysql/dedi.niresh.co.err file
    Increasing the query_cache size over 128M may reduce performance
    When making adjustments, make tmp_table_size/max_heap_table_size equal
    Reduce your SELECT DISTINCT queries which have no LIMIT clause
    Consider installing Sys schema from https://github.com/mysql/mysql-sys
Variables to adjust:
    query_cache_size (=0)
    query_cache_type (=0)
    query_cache_size (> 128M) [see warning above]
    tmp_table_size (> 64M)
    max_heap_table_size (> 64M)
    innodb_log_file_size should be (=192M) if possible, so InnoDB total log files size equals to 25% of buffer pool size.

쿼리 캐시를 꺼야 합니까?

더 추천할 만한 게 있나요?

거의 모든 프로덕션 서버에서는 쿼리 캐시를 해제하는 것이 좋습니다.테이블을 수정할 때마다 해당 테이블의 모든 QC 항목이 삭제됩니다.테이블이 클수록 시간이 오래 걸립니다.128M은 위험할 정도로 높습니다.

통상, 설정해 두는 것이 현명합니다.innodb_buffer_pool_sizeRAM의 약 70%까지 확장 가능.데이터 세트 크기보다 훨씬 낮은 값으로 설정되었습니다.3G가 도움이 될 것입니다. 20G는 더 이상 도움이 되지 않습니다(데이터셋이 크게 증가할 때까지).

OS와 MySQL이 모두 64비트 버전인지 확인합니다.

보다 철저한 분석을 위해

• RAM 크기(32G)
• SHOW VARIABLES;
• SHOW GLOBAL STATUS;(24시간 이상 실행 후)

변수 및 상태 분석:

더 중요한 문제

InnoDB만 사용하고(?) 데이터는 2GB밖에 없기 때문에 다음과 같은 코멘트에 응답하는 것은 중요하지 않습니다.innodb_buffer_pool_size그리고.key_buffer_size

사용 빈도에 대한 자세한 내용을 기입해 주십시오.DELETE.

slowlog를 사용하여 '최악' 쿼리를 찾습니다.자세한 것은 이쪽.tmp_table과 테이블스캔의 문제를 다음에 나타냅니다.

번거롭게 사용할 필요가 없다OPTIMIZE TABLE.

'거래'는 잘 되고 있습니까?때로는 자동 커밋으로, 때로는COMMIT?

상세 및 기타 관찰사항

( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6%-- 사용된 key_buffer 비율.High-water-mark. -- 불필요한 메모리 사용을 방지하기 위해 key_buffer_size를 낮춥니다.

( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5%-- InnoDB buffer_pool에 사용되는 RAM의 %

( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (128M / 0.20 + 4096M / 0.70) / 32768M = 19.8%-- 사용 가능한 RAM의 대부분은 캐시에 사용할 수 있어야 합니다.-- http://mysql.rjweb.org/doc.php/memory

( Innodb_buffer_pool_pages_free * 16384 / innodb_buffer_pool_size ) = 187,813 * 16384 / 4096M = 71.6%-- buffer pool free -- buffer_pool_size가 작업 세트보다 큽니다.그 값을 줄일 수 있습니다.

( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9%-- 디스크에 히트해야 했던 쓰기 요청 -- innodb_buffer_pool_size를 확인합니다.

( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9%-- 데이터가 차지하는 버퍼 풀의 퍼센티지 -- 작은 퍼센트는 buffer_pool이 불필요하게 크다는 것을 나타낼 수 있습니다.

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234-- InnoDB 로그 순환 간격(분)5.6.8부터는 동적으로 변경할 수 있습니다.my.cnf.도 변경해 주세요.innodb_log_file_size를 조정합니다.(AWS에서는 변경할 수 없습니다.)

( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 (되는 경우 -- Churren -- "MySQL" (MySQL)

( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% 및 시켜 주세요) "tmp_table_size" - max_heap_table_size" 입니다.블롭 등을 피합니다.

( Select_scan ) = 871,872 / 533153 = 1.6 /sec풀 쿼리 테이블이 -- " - " / " " ( " " " )

( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% % of of of of of of of full table 을 （ index / optimize query ( ） 。

( Com_optimize ) = 216 / 533153 = 1.5 /HR -- 되지 .-- OPTIME 탭LE - OPTIME 탭LEE le le le le le le le le le le le물론 높은 빈도는 아닙니다.

( long_query_time ) = 10.000000 = 10 "컷오프( 2 -- " " 저저"""--초초초초초초초초초초초초초"(초) -- 초 2

극단(주석 없음):

비정상적으로 작음:

Com_commit = 2.5 /HR
Innodb_buffer_pool_pages_made_not_young = 0.15 /sec
Innodb_ibuf_merged_delete_marks = 27 /HR
Innodb_row_lock_time = 8
Innodb_row_lock_time_max = 1
interactive_timeout = 360

비정상적으로 크다:

Com_rollback_to_savepoint = 14 /HR
Handler_savepoint_rollback = 14 /HR
join_cache_level = 8   (This may be unused?  It was removed in 5.6.3, but possibly left in MariaDB 10.1?)

비정상적인 문자열:

Innodb_buffer_pool_dump_status = Dumping buffer pool(s) not yet started
Innodb_buffer_pool_load_status = Loading buffer pool(s) not yet started
innodb_checksum_algorithm = INNODB
innodb_cleaner_lsn_age_factor = HIGH_CHECKPOINT
innodb_empty_free_list_algorithm = BACKOFF
innodb_force_load_corrupted = OFF
innodb_foreground_preflush = EXPONENTIAL_BACKOFF
innodb_log_checksum_algorithm = INNODB
myisam_stats_method = NULLS_UNEQUAL
opt_s__engine_condition_pushdown = off
opt_s__mrr = off
opt_s__mrr_cost_based = off

쿼리 캐시

이 기능이 꺼졌기 때문에 Qcache 상태 값이 설정되지 않았습니다.그래서 나는 원래의 질문에 대답할 수 없다.QC를 켜고 서버를 재시작하고 며칠을 기다리려면 QC를 켜고 다시 분석할 수 있습니다.히트, 자두 등에 관한 다양한 메트릭을 사용하여 원래의 질문에 대응할 수 있습니다.

네, 쿼리 캐시를 꺼야 합니다.

have_query_cache=0        # from Yes 08/19/2017 to avoid QC overhead, just by its presence
query_cache_size=0        # to ensure QC can not be used
read_rnd_buffer_size=16K  # from 256K 08/19/2017 to minimize wasted RD cycles

를 묻다max_allowed_packet=268435456이것이 이 될 수 있습니다.net_buffer_length크기를 증가시키고 기억 스트레스를 유발합니다.

추가 권장 사항(원래 질문에서 요청한 대로)

Rick James 제안 외에 [mysqld] 섹션의 .cfg/ini에 대해 한 번에 하나씩 다음 내용을 참조하십시오.

최적기가 40억 ndx의 검색을 허용하는 것이 아니라 max_discs_for_key = 64 # 입니다.
innodb_log_size_size = 64M #16M에서 HDD 쓰기 빈도 감소max_connections = 200 #500부터123개밖에 사용되지 않았기 때문에(HWM)테이블을 열어두려면 table_open_cache = 4000 #1024부터table_definition_cache = 3000 #400부터 테이블 정의를 열어 둡니다.파일을 열어두려면 open_files_limit = 30000 #10000부터

상태 변수는 다음을 나타냅니다.com_stmt_prepare9, 9,391,427만 .com_stmt_close 을 해방하기 이들 수 . 자원을 해방하기 위해 이들 수천 명을 폐쇄할 필요가 있을 수 있습니다.

진행 상황을 알려주세요.

JYelton, variable_value 뒤에 있는 #의 목적은 [mysqld] 함수의 끝에 빠르게 복사/붙여넣기를 허용하고 오래된 값이 무엇이었는지 알아내는 것입니다.포맷에 대한 조언 감사합니다.

언급URL : https://stackoverflow.com/questions/45412537/should-i-turn-off-query-cache-in-mysql