velmi velká tabulka mysql a hlášení

Začněte tím, že se podíváte do partition ing vašeho stolu, pokud jste tak ještě neučinili:

Jak „konsolidujete“ svá data? Možná metoda, kterou používáte, není optimální. Jedním dobrým přístupem (dejte mi vědět, zda to skutečně děláte) je vytvořit tabulku, která obsahuje agregovaná data. Pak to nastavte takto:

Nejprve ponechte stranou, jak se data ukládají do vaší hlavní tabulky...

Vytvořte úlohu (cron nebo cokoli, co máte po ruce nebo již nakonfigurované), která se spouští v zadaném intervalu vzhledem k tomu, jak jsou data načítána do hlavní tabulky (říkejme tomu MAIN , pohyb vpřed). Pokud se vaše HLAVNÍ tabulka načítá každou hodinu, synchronizujte ji. Půlhodinu? Na tom nezáleží. Rychlost můžete zkontrolovat tak jako tak, nebo pokud se vaše přehledy spouštějí téměř mimo špičku, naplánujte si to blízko
Správně indexujte tabulku pro konsolidovaná data. Říkejme tomu AGG posun vpřed.
Vytvořte uloženou proceduru, která načte data z MAIN do AGG, což je v podstatě AGG LOAD FOR INTERVAL-? . Samozřejmě jste zde jediný, kdo ví, jak a kdy se data vkládají do MAIN, takže budete také tím, kdo ví, jaký je záměr agregace. Je také možné ponechat spouštěcí agregační uloženou proceduru, pokud není záměr agregace dokončen (řekněme, že je to na celý den... takže je to kumulativní běh, dokud není nastaveno)
Použijte STAGING tabulky. Pro mě jsou nejlepší .
Vytvořte uloženou proceduru, která znovu zkontroluje data, aby se případné aktualizace nebo dodatečné vložení záznamů mohly projevit v tabulce AGG spuštěním této procedury. Zahrňte parametry pro rozsah, který chcete aktualizovat. Pokud je to denně, pak máte DAILY AGG LOAD a DAILY AGG RELOAD postup. Zahrňte AGG CHECK INTERVAL a AGG CHECK DAILY postup, který vám pomůže v noci dobře spát. Jo a nemluvě o AGG DATA HOLE CHECK nebo MISSING AGG DATA CHECK a uplatňovat obchodní pravidla, která implementují kontrolu požadovaného minimálního množství dat, která můžete získat z agregované tabulky nebo z hlavní tabulky nebo pracovní tabulky (nejlépe)
Samozřejmě nikdy neupravujte AGG stůl. Vždy jej pouze znovu načtěte.
Jak to pomáhá? Nebylo by potřeba, aby se vaše přehledy dotazovaly pouze na AGG? tabulka, která je menší a rychlejší (protože agregace již byla provedena)? Problém s výkonem možná přichází s intervalovým načítáním, ale pokud správně strukturujete svou tabulku, její indexy a její údržbu, mělo by to stát za to.
Kde se bere dělení? Archivace. Jakmile uplyne určitý čas (prodiskutujte, co je přijatelné se svým týmem/šéfem/topmanem), můžete archivovat stará data z MAIN . Zažil jsem nutnost uchovávat data za 1 rok v produkční databázi. Připadalo mi to jako překážka, ale protože to byl požadavek klienta, společnost neměla jinou možnost, než mi dát místo na disku, které jsem potřeboval (mne si ruce), a chlapče, hrál jsem si s tím, dokud jsem nezačal něco slušně fungovat. Musím zmínit, že moje zkušenost byla s Microsoft SQL Server 2005 a díky uloženým procedurám a SSIS to bylo zábavné.

To je vše, pokud to ještě nevíte, a pro ostatní, kteří mohou chtít zvážit možnosti. Neříkám, že jste nic z výše uvedeného již neznali; Uvádím pouze to, co jsem mohl udělat dříve – vzhledem k tomu, že jsem z vašeho příspěvku neměl více informací, se kterými bych mohl pracovat, kromě toho, že máte proces konsolidace, který jste zkusili.