MyISAM eller InnoDB

Hvis du bruger transaktioner, så skal du jo ikke bruge MyIsam. Opdatering af transaktionsloggen koster selvfølgelig, men man får muligheden for transaktioner til gengæld. Du bruger indexer på tabellerne korrekt?

Ja det er jo et godt spørgsmål om jeg bruger index korrekt :-)
Jeg har index på de felter jeg søger mest på og de felter der bruges af queries til joins, så jeg mener ikke der et meget at hente der.

Og jeg bruger ikke transaktioner.

"en form for datawarehouse" lyder seriøst ;)  Så jeg undrer mig over at du ikke skulle have behov for transaktioner. At sætte rigtige indexer på er både en kunst og en videnskab - kig på EXPLAIN kommandoen i MySql. Det tager lidt mere end 5 minutter at lære at bruge den, men tiden er tjent godt hjem.

Jeg samler data op fra en masse Paradox filer som jeg gemmer på en MySQL server - den del er i orden og kører i et Delphi program jeg har lavet til formålet.
(samling af data ~ datawarehouse)

Alle disse data skal jeg så kunne bruge til nogle udtræk af omsætningstal som jeg laver som rapporter i en M$ Access db der connecter via ODBC

Mht index, er det en god ide at aktivere MySQL's logning af langsomme forespørgsler, og bruge dem som udgangspunkt for at oprette indexes (sammen med explain), fremfor at kaste en masse tilfældige index på (udover de indlysende på primær/fremmednøgler)

Kan du fortælle mig hvordan jeg aktiverer den logning?

i din my.cnf (typisk /etc/mysql på linux), skal du udkommentere/tilpasse flg. linier:

# hvor skal logfilen placeres
log_slow_queries        = /var/log/mysql/mysql-slow.log

# hvad er grænsen for hvad en langsom query er
long_query_time = 1

# evt. udkommenter denne, som vil logge samtlige queries som ikke benytter et eller andet index
#log-queries-not-using-indexes


du kan evt bruge mysqldumpslow kommandoen til at vise indholdet af logfilen (den sammenskriver varianter af samme queries

Kun et par bemaerkninger:

1)  log og EXPLAIN til at finde problemet lyder som en god strategi

2)  hvis det er muligt at skifte fra ODBC til et andet database API, saa kunne
    det muligvis forbedre performance

3)  jeg er ikke overrasket over at der ikke bruge transaktioner i en DWH database,
    transaktioner er absolut noedvendige i en OLTP database, men en DWH datase er
    ofte en natlig ETL process og saa query only

Jeg kender ikke anden mulighed end ODBC hvis Access og MySQL skal snakke sammen. Og jeg kender slet ikke andre værktøjer der har samme gode rapportmuligheder som Access (og så har jeg altid brugt Access og er efter bedste overbevisning ret god til det :-) )

Jeg synes både arne_v og erik skal smide et svar. Så kan i deles om point for jeres input.

Ingen point til mig, tak.

Du kunne prøve en ADO provider til MySQL f.eks.:
  http://sourceforge.net/projects/myoledb/

Nogen gange performer ADO bedre end ODBC.

Men måske ligger problemet i Access - det er jo high-end.

Andre kendte rapport tools er Crystal Reports og Business Objects. Men prisen på dem er prisen på Access i anden eller tredie !

Og et svar.

myoledb findes så vidt jeg kan finde frem til kun til 32bit Windows og jeg sidder med en monstermaskine med XP 64 på, så det vil nok ikke gå godt.

Crystal Reports brugte jeg for mange år siden til VB inden jeg fandt en genvej til at lave rapporterne i Access og så kalde dem fra mit VB program. Det var lidt dirty programmering men det virkede. Jeg syntes nemlig at Crystal Reports i daværende udgave var noget skrammel - men det er vel 15 år siden så det er vel blevet bedre.
Business Objects kender jeg ikke.
Det jeg godt kan lide ved Access er at det er nemt/hurtigt at designe en rapport og så kan man ellers programmere sig ud af næsten alle tænkelige brugerdumheder. Og når man skal lave noget der skal bruges af andre, er det et must :-)