Antal tabeller i en MySQL database

jeg mener ikke at der er nogen begrænsning på antal tabeller

men jeg vil betstemt fraråde at splitte en stor tabel ud i mange små
tabeller

masser af ekstra kode arbejde og dårligere performance (forudsat at den store
tabel har de rigtige index !)

Det er svært at indexere den store tabel da alle felter bruges i hver forespørgelse til den (hvilket sker ca. 300 gange i sekundet) Men det er gjort så godt som muligt.
Masser af esktra kode arbejde er jeg uenig i.

phpMyAdmin kan ikke læse efter jeg har lavet 2000+ tabeller i mit testmiljø. Men jeg kan godt lave en læsning med et php-script og finde alle tabellerne.

det er så en bug en PHPMyAdmin

hvis du skal til at have fat i data fra flere tabeller med UNION så bliver du hurtigt
træt af det

med optimale index så tror jeg ikke på performance forbedringer ved den
opsplitning

men om de er optimale kan naturligvis ikke afgøres uden at kender tabel struktur,
indexes og typiske queries

har du styr på disk fragmentering og intern fragmentering ?

Vi har styr på alle disse ting.
Ved ikke hvor store systemer du normalt arbejder med, men vi er på et punkt, hvor den nuværende løsning med en tabel ikke længere kan bruges.
Hvor vidt vi skal bruge løsningen med en tabel pr. type er så en anden ting :) Nu og her skulle jeg blot vide om det kan lade sig gøre og om det er forsvarligt at våge sig ud i det.

arbejdsmæssigt: betydeligt større systemer, men det er ikke på MySQL

jeg synes dog slet ikke at 25 millioner rækker lyder slemt

hvis man læser nogle af MySQL success historierne så opererer de med
hundredevis af GB og milliarder af rækker - de fortæller ikke om max. antal rækker
per tabel, men hvis man har 2 milliarder rækker så har man sikkert også
en enkelt tabel med mere end 25 millioner rækker (Cox indsætter 2 millioner
rækker i timen !)

men OK - der kan være specielle forhold for jer

men generelt tror jeg ikke at en opslitning af en tabel i flere tabeller
vil forbedre performance

om I falder ind i "generelt" kategorien kan kun I afgøre (ihvertfald
på de foreliggende oplysninger)

Det der er hovedproblemet er, hvis tabellen går i "stykker". Så skal der laves repair og det tager mange lede minutter, det har vi ikke tid til.

ah - gode gamle myisamchk

ja - det er faktisk et argument for at splitte op

jeg formoder at I har forsøgt at finde ud af hvorfor de går i stykker

eneste alternativ jeg kan tænke på er replikering og failover til en backup server

replikering og failover har vi. Dette holder jo bare ikke hvis begge ryger samtidigt.
Hvorfor de går i stykker arbejder vi på at fejlsøge, det kan dog være svært at finde jo :(

de ryger begge samtidigt ?

så:
- det må så være en mysql fejl ikke en hardware eller styresystem eller app fejl
- det hjælper naturligvis ikke at replikere
- fejl må kunne genskabes ved at restore en dump og apply'e en binlog på
  et test system => mysql bør kunne finde den (forudsat at I betaler for support)

er jeres data struktureret således at I f.eks. kunne splitte i 2 tabeller:
  idag (write & read)
  ældre (read only)
?

hvis I er langt fra performance limit kunne I prøve med InnoDB (men det koster altså
i performance)

De ryger ikke begge samtidigt.
MySQL fejl er jeg enig i.
Fejl kan nok genskabes ja.
Pt. er der igen splitning på tabellen.

Vi har kun oplevet den er røget 2 gange. Den ene gang var det selvforskyldt da vi var nødt til at kværke en server.
Anden gang røg en masse tabeller samtidigt meget pludseligt.
Vi havde netop opdateret til MySQL 4.1.16 fra 4.0.? Man kunne forestille sig dette har skabt problemerne for os. Jeg har ikke set problemer siden vi fik den repereret sidst.

hvis ikke de ryger samtidigt så kan replikering og failover vel cover
indtil den er klar igen

Teoretisk set jo.
Jeg kan ikke komme dybere ind på det område nu.

hvis der kun er sket en gang og ikke på begge systemer er det ikke ikke til
at sige med sikkerhed at det er MySQL

hvis der gik mange tabeller samtidigt vil jeg nok mistænke hardware/styresystem
mest selvom intet kan udelukkes

Vi har en mistanke om, at et cron job er gået skævt eller lign.
Vi har nemlig et cron som ryder op i en del tabeller og man kunne forestille sig Apache på et tidspunkt har givet op, fordi MySQL har knoklet og knoklet. Herefter har Apache lukket ned for forbindelsen, mens MySQL fortsat har knoklet på. Dvs. tråden aldrig er blevet lukket.

Smid et svar arne_v

ok