mycket stor mysql-tabell och rapportering

Börja med att titta på partition i ditt bord om du inte redan har gjort det:

Hur "konsoliderar" du din data? Kanske är metoden du använder inte optimal. Ett bra tillvägagångssätt (låt mig veta om det verkligen är det du gör) är att skapa en tabell som innehåller aggregerad data. Ställ sedan in det så här:

Lägg först åt sidan hur data dumpas i din huvudtabell...

Skapa ett jobb (cron eller vad du kan ha till hands eller redan konfigurerat) som körs med ett specificerat intervall, i förhållande till hur data laddas in i huvudtabellen (låt oss kalla det MAIN , går vidare). Om din MAIN-tabell laddas varje timme, synkronisera den. En halvtimme? spelar ingen roll. Du kan kontrollera hastigheten hur som helst, eller om det är nära lågtrafik som dina rapporter körs, schemalägg sedan nära då
Indexera din tabell korrekt för konsoliderad data. Låt oss kalla det AGG framåt.
Skapa en lagrad procedur som laddar data från MAIN till AGG, vilket i grunden är en AGG LOAD FOR INTERVAL-? . Naturligtvis är du den enda här som vet hur eller när data infogas i MAIN, så du kommer också att vara den som vet vad aggregeringsavsikten är. Det är också möjligt att fortsätta köra den lagrade aggregeringsproceduren om aggregeringsavsikten inte är slutförd (säg att det är en hel dag... så det är en ackumulerande körning tills den är inställd)
Använd STAGING tabeller. För mig är de bäst .
Skapa en lagrad procedur som omkontrollerar data, så att eventuella uppdateringar eller ytterligare infogning av poster kan återspeglas i AGG-tabellen genom att köra den här proceduren. Inkludera parametrar för intervallet som ska uppdateras. Om det är dagligen har du en DAILY AGG LOAD och DAILY AGG RELOAD procedur. Inkludera ett AGG CHECK INTERVAL och AGG CHECK DAILY procedur som hjälper dig att sova gott på natten. Åh och för att inte tala om en AGG DATA HOLE CHECK eller en MISSING AGG DATA CHECK och tillämpa affärsregler som implementerar kontroll av en nödvändig minsta mängd data som du kan få från den aggregerade tabellen eller från huvudtabellen eller mellanställningstabellen (helst)
Ändra naturligtvis aldrig AGG tabell. Ladda alltid bara om den.
Hur hjälper detta? Skulle du då inte bara behöva låta dina rapporter fråga AGG tabell, som är mindre och snabbare (eftersom aggregeringen redan har gjorts)? Kanske kommer prestandaproblemet med intervallladdningen, men om du strukturerar din tabell, dess index och underhåll på rätt sätt, borde det vara värt det.
Var kommer partitionering in? Arkivering. När en viss tid har gått (diskutera vad som är acceptabelt med ditt lag/chef/toppman) kan du arkivera den gamla data från MAIN . Jag upplevde att jag fick behålla 1 års data i produktionsdatabasen. Det kändes lite som ett drag, men eftersom det var kundens begäran hade företaget inget annat val än att ge mig det diskutrymme jag behövde (gnuggar händerna) och jag lekte med det tills jag fick något att fungera ordentligt. Jag måste nämna att min erfarenhet var med Microsoft SQL Server 2005, och lagrade procedurer och SSIS gjorde det roligt.

Detta är allt om du inte redan vet det, och för andra som kanske vill överväga alternativ. Jag säger inte att du inte visste något av ovanstående redan; Jag säger bara vad jag har kunnat göra tidigare -- med tanke på att jag inte hade mer information att arbeta med från ditt inlägg, förutom att du har en konsolideringsprocess som du försökt..