Det finns ingen bra generell lösning på frågan "Hur stort är för stort" - sådana problem är ofta beroende av vad du gör med din data och vad dina prestationsöverväganden är.
Det finns några grundläggande begränsningar för bordsstorlekar. Du kan inte ha fler än 1000 kolumner. Dina poster får inte vara större än 8k vardera. Dessa gränser ändras beroende på databasmotor. (De här är för InnoDB.)
Det låter som att du har slagit samman flera olika datamängder till en tabell. Du har förmodligen några fält som talar om vilken datauppsättning denna post avser, tillsammans med några datafält och viss tidsstämpelinformation. Det är inte särskilt omfattande (såvida du inte loggar t.ex. alla indataparametrar för varje begäran.) Ditt största problem kommer att vara med selektivitet . Att indexera den här tabellen på ett meningsfullt sätt kommer att vara en utmaning. Om dina vanliga fält kan vara tillräckligt selektiva så att du kan använda dem för att komma till de poster du vill ha utan att konsultera tabellen, kommer det att vara ett stort plus. (Jfr tabellskanning)
För så många poster per dag (i princip två per sekund hela dagen, och jag antar att du har en toppbelastningsperiod där den är mycket högre), vill du också se till att du specifikt tittar på optimeringar på förbättra insättningshastigheten . Som en allmän regel, fler index =långsammare infogning. Om du kan, överväg att helt arkivera föråldrade poster till en annan tabell. På tidigare arbetsplatser har vi använt en arkiveringsstrategi av Förra månaden, föregående tre månader, föregående sex månader, var och en i separata tabeller. En annan idé är att radera äldre poster. Många miljöer behöver helt enkelt inte information efter ett visst datum. Att hänga på loggningsposter från tre månader sedan är ofta för dyrt.
Slutligen, försumma inte den fysiska lagringen av ditt bord. Ju tunnare dina poster är, desto mindre fysisk IO behöver förekomma för att läsa (eller för den delen, infoga) en post. Du kan lagra dina index på en separat fysisk hårddisk. Om det finns många överflödiga data i dina poster kan tabellen lagras komprimerad faktiskt vara en hastighetsökning. Om du har lite pengar att förbränna, överväg värdet av en bra RAID-array för att strippa dina data.
Så, för att svara på din grundläggande fråga:det är många skivor, men med ett noggrant öga mot stämning kommer det inte att vara ett problem.