много голяма mysql таблица и отчитане

Започнете, като разгледате partition в таблицата ви, ако още не сте го направили:

Как „консолидирате“ данните си? Може би методът, който използвате, не е оптимален. Един добър подход (уведомете ме дали това всъщност е това, което правите) е да създадете таблица, която съдържа обобщени данни. След това го настройте по следния начин:

Първо да оставим настрана как данните се изхвърлят във вашата основна таблица...

Създайте задание (cron или каквото може да имате под ръка или вече конфигурирано), което се изпълнява на определен интервал, в зависимост от това как данните се зареждат в основната таблица (нека го наречем MAIN , движа се напред). Ако вашата MAIN таблица се зарежда всеки час, след това я синхронизирайте. На половин час? Няма значение. Все пак можете да проверите скоростта или ако отчетите ви се изготвят близо до непиковите часове, след това насрочете близо до тогава
Правилно индексирайте вашата таблица за консолидирани данни. Нека го наречем AGG върви напред.
Създайте съхранена процедура, която зарежда данни от MAIN към AGG, което по същество е AGG LOAD FOR INTERVAL-? . Разбира се, вие сте единственият тук, който знае как или кога данните се вмъкват в MAIN, така че вие също ще сте този, който знае какво е намерението за агрегиране. Възможно е също така да продължите да изпълнявате съхранената процедура за обобщаване, ако намерението за агрегиране не е завършено (да речем, че е за цял ден.. така че това е натрупващо изпълнение, докато не бъде зададено)
Използвайте STAGING маси. За мен те са най-добрите .
Създайте съхранена процедура, която проверява повторно данните, така че всякакви актуализации или допълнително вмъкване на записи да могат да бъдат отразени в таблицата на AGG, като изпълните тази процедура. Включете параметри за обхвата за актуализиране. Ако е ежедневно, тогава имате DAILY AGG LOAD и DAILY AGG RELOAD процедура. Включете AGG CHECK INTERVAL и AGG CHECK DAILY процедура, която ще ви помогне да спите добре през нощта. О, и да не говорим за AGG DATA HOLE CHECK или MISSING AGG DATA CHECK и прилагайте бизнес правила, които прилагат проверка за необходимото минимално количество данни, които можете да получите от обобщената таблица или от основната таблица или таблицата за етапи (за предпочитане)
Разбира се, никога не променяйте AGG маса. Винаги го презареждайте само.
Как помага това? Не би ли трябвало да накарате вашите отчети да заявят само AGG таблица, която е по-малка и по-бърза (тъй като агрегирането вече е извършено)? Може би проблемът с производителността идва с интервалното зареждане, но ако структурирате правилно вашата таблица, нейните индекси и нейната поддръжка, би трябвало да си струва.
Къде идва разделянето? Архивиране. След като изтече определено време (обсъдете какво е приемливо с вашия екип/шеф/върховен човек) можете да архивирате старите данни от MAIN . Имах нужда да съхранявам данни за 1 година в производствената база данни. Това беше нещо като плъзгане, но тъй като това беше заявка на клиента, компанията нямаше друг избор, освен да ми даде необходимото дисково пространство (потрива ръце) и момчето си поиграх с него, докато не накарам нещо да работи прилично. Трябва да спомена, че моят опит беше с Microsoft SQL Server 2005, а съхранените процедури и SSIS го направиха забавно.

Това е всичко, ако вече не го знаете и за други, които може да искат да обмислят варианти. Не казвам, че вече не сте знаели нищо от горното; Посочвам само това, което успях да направя преди - като се има предвид, че нямах повече информация, с която да работя от публикацията ви, освен че имате процес на консолидация, който опитахте..