it-swarm-eu.dev

způsob, jak zabránit tomu, aby dotazy čekaly na zámek na úrovni tabulky

Setkali jsme se s problémem po přesunutí databáze našeho zákazníka na další server. To mělo mít pozitivní vliv na výkon webu, ale v MyISAMu je problém se zamykáním tabulek. (Slyšel jsem o použití InnoDB místo MyISAM, ale v blízké budoucnosti nemůžeme motor změnit).
Mohli bychom jej najít na aktualizačním dotazu, který se provede, když moderátor aktivuje komentář k článku. Toto je proces:

  • update-query je zpracován SET status = 1 WHERE id = 5 (nastaven index)
  • soubory v mezipaměti stránky se odstraní

V tomto okamžiku se celá stránka zpomalí. Samotná databáze je zaneprázdněna několik minut. Několikrát jsem vyvolal seznam procesů a viděl jsem asi 60 položek různých výběrových dotazů, které byly všechny ve stavu čekání na zámek úrovně tabulky.

1. Nechápu, proč tato aktualizace v tabulce article_comments může ovlivnit příkazy select pro tabulku article čekat na uzamčení úrovně tabulky. V seznamu procesů byly téměř všechny čekající dotazy z této tabulky. Četl jsem o skutečnosti, že aktualizace/přílohy jsou preferovány před výběry a že to může způsobit takové problémy, ale samotná tabulka článků se neaktualizuje, když se komentáře aktivují, takže výběry by neměly čekat. Stýskalo se mi to?
2. Existuje něco kromě změny na InnoDB, aby se tomuto chování zabránilo nebo alespoň aby ​​se dosáhlo lepší rovnováhy? Jsem velmi podrážděný skutečností, že se tento problém neobjevil před přesunutím databáze na nový server. Myslím, že existuje nějaká nesprávná konfigurace, ale nevím, jak ji identifikovat.

10
32bitfloat

MyISAM Storage Engine je zuřivě notoricky známý pro provádění úplných zámků stolů pro libovolný DML (INSERTs, UPDATEs, DELETE). InnoDB by tuto otázku definitivně vyřešil z dlouhodobého hlediska.

Psal jsem o výhodách a nevýhodách používání MyISAM vs InnoDB

S ohledem na vaši současnou otázku je zde možný scénář:

  • article a article_comments jsou obě tabulky MyISAM
  • article_comments má jeden nebo více indexů s status jako sloupcem
  • Aktualizace indexové stránky pro article_comments jsou uloženy v mezipaměti v MyISAM Key Buffer (velikost ) key_buffer_size ), což způsobuje staré stránky indexu z MyISAM Key Buffer
  • Máte dotazy SELECT, které provádějí spojení mezi article a article_comments

V mém navrhovaném scénáři lze SELECT proti tabulce article vydržet z povolování zápisů, protože museli čekat na article_comments být bez jakéhokoli DML (v tomto případě UPDATE)

8
RolandoMySQLDBA

V tomto okamžiku se celá stránka zpomalí. Samotná databáze je zaneprázdněna několik minut.

Voní to, že máte velkou Query_cache?

mysql> SHOW VARIABLES LIKE 'query_cache%';
+------------------------------+----------+
| Variable_name                | Value    |
+------------------------------+----------+
| query_cache_limit            | 1048576  |
| query_cache_min_res_unit     | 4096     |
| query_cache_size             | 16777216 | -- Not over 50M
| query_cache_type             | DEMAND   | -- Only if using SQL_CACHE
| query_cache_wlock_invalidate | OFF      |
+------------------------------+----------+

U produkčních systémů se spoustou zápisů můžete také vypnout query_cache.

Všechny položky v query_cache pro danou tabulku jsou vymazány, když dojde k nějaké zápis do této tabulky. Čím větší je QC, tím pomalejší je tento úkol.

MyISAM používá zámky na úrovni tabulky. Čtení a zápis nelze provádět současně (ve stejné tabulce). Surový, ale efektivní.

7
Rick James