sql >> Databáze >  >> RDS >> Mysql

Mám vypnout Query Cache v MySQL?

Téměř na všech produkčních serverech je rozumné vypnout mezipaměť dotazů. Každý úprava tabulky způsobí vymazání všech Záznamy kontroly kvality pro tuto tabulku. Čím větší stůl, tím více času to zabere. 128M je nebezpečně vysoká hodnota.

Normálně je rozumné nastavit innodb_buffer_pool_size na přibližně 70 % dostupných RAM. Máte ji nastavenou na mnohem nižší hodnotu, dokonce menší než je velikost datové sady. 3G by asi pomohlo. 20G by už nepomohlo (dokud se vaše datová sada výrazně nerozroste).

Ujistěte se, že operační systém i MySQL jsou 64bitové verze.

Pro důkladnější analýzu poskytněte

  • Velikost RAM (32G)
  • SHOW VARIABLES;
  • SHOW GLOBAL STATUS; (po běhu alespoň 24 hodin)

Analýza PROMĚNNÝCH a STAVU:

Důležitější problémy

Vzhledem k tomu, že používáte pouze (?) InnoDB a pouze 2 GB dat, není důležité reagovat na komentáře týkající se innodb_buffer_pool_size a key_buffer_size

Uveďte další podrobnosti o častém používání DELETE .

Využijte slowlog k nalezení „nejhorších“ dotazů. Další podrobnosti zde . To by mělo identifikovat níže uvedené problémy s tmp_table a skenováním tabulek.

Neobtěžujte se používáním OPTIMIZE TABLE .

Jak jste na tom s "transakcemi"? Někdy pomocí automatického potvrzení, někdy pomocí COMMIT ?

Podrobnosti a další postřehy

( Key_blocks_used * 1024 / key_buffer_size ) = 4,710 * 1024 / 128M = 3.6% -- Procento použitého key_bufferu. High-water-mark.-- Snižte velikost key_buffer_size, abyste předešli zbytečnému využití paměti.

( innodb_buffer_pool_size / _ram ) = 4096M / 32768M = 12.5% -- % paměti RAM použité pro InnoDB buffer_pool

( (key_buffer_size / 0.20 + innodb_buffer_pool_size / 0.70) / _ram ) = (128M / 0.20 + 4096M / 0.70) / 32768M = 19.8% -- Většina dostupné paměti ram by měla být zpřístupněna pro ukládání do mezipaměti. -- 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 je větší než pracovní sada; mohl snížit

( Innodb_pages_written / Innodb_buffer_pool_write_requests ) = 7,144,121 / 29935426 = 23.9% -- Zápis požadavků, které musely zasáhnout disk -- Zkontrolujte innodb_buffer_pool_size

( Innodb_buffer_pool_bytes_data / innodb_buffer_pool_size ) = 1,199,046,656 / 4096M = 27.9% -- Procento fondu vyrovnávací paměti zabrané daty -- Malé procento může indikují, že buffer_pool je zbytečně velký.

( Uptime / 60 * innodb_log_file_size / Innodb_os_log_written ) = 533,153 / 60 * 512M / 20356473344 = 234 -- Minuty mezi rotacemi protokolu InnoDB Počínaje verzí 5.6.8 lze toto měnit dynamicky; nezapomeňte také změnit my.cnf.-- (Doporučení 60 minut mezi rotacemi je poněkud libovolné.) Upravte innodb_log_file_size. (Nelze změnit v AWS.)

( Innodb_rows_deleted / Innodb_rows_inserted ) = 364,605 / 414950 = 0.879 -- Churn-- "Nestavte to do fronty, prostě to udělejte." (Pokud se MySQL používá jako fronta.)

( Created_tmp_disk_tables / (Created_tmp_disk_tables + Created_tmp_tables) ) = 247,373 / (247373 + 446152) = 35.7% -- Procento dočasných tabulek, které se vysypaly na disk -- možná zvýšit tmp_table_size a max_heap_table_size; vyvarujte se kapek atd.

( Select_scan ) = 871,872 / 533153 = 1.6 /sec -- úplné prohledání tabulek -- Přidání indexů / optimalizace dotazů (pokud se nejedná o malé tabulky)

( Select_scan / Com_select ) = 871,872 / 12593904 = 6.9% -- % vybraných provádějících úplné prohledání tabulky. (Uložené rutiny mohou být oklamány.)-- Přidat indexy / optimalizovat dotazy

( Com_optimize ) = 216 / 533153 = 1.5 /HR -- Jak často se provádí OPTIMIZE TABLE. -- OPTIMIZE TABLE je málokdy užitečná, rozhodně ne při vysoké frekvenci.

( long_query_time ) = 10.000000 = 10 -- Cutoff (sekundy) pro definování "pomalého" dotazu.-- Návrh 2

Extrémy (bez komentáře):

Abnormálně malý:

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

Neobvykle velké:

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?)

Abnormální řetězce:

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

Vyrovnávací paměť dotazů

Vzhledem k tomu, že byla vypnuta, nebyly nastaveny žádné hodnoty stavu Qcache. Nemohu tedy odpovědět na původní otázku. Pokud byste chtěli zapnout kontrolu kvality a restartovat server a počkat několik dní, mohl bych s tím znovu provést analýzu. Různé metriky týkající se hitů, sušených švestek atd. mohou řešit původní otázku.



  1. Jak získat číselné typy z MySQL pomocí PDO?

  2. ORA-30926:při slučování tabulek nelze získat stabilní sadu řádků ve zdrojových tabulkách

  3. MySQL:Získejte nejnovější položky starší než xxx, Výkon

  4. SQL:AKTUALIZACE z komplexního výběru