Non conosco il tuo background, ma 9 su 10 in caso di utenti poco esperti, il problema è proprio la strutturazione di Query non adeguate, magari disperdendo dei controlli DataBound come Combo/ListBox con altrettante Query assegnate a RowSorce non propriamente ottimizzate.
Ti faccio un esempio banale.
QUERY LENTA
SELECT * FROM T1
WHERE Campo1=[Forms]!NomeForm!NomeTextBox
Questa query non viene risolta dal motore MySQL, in quanto non in grado di capire cosa sia la WHERE... l'oggetto a cui si fa riferimento infatti per MySQL è intraducibile.
La conseguenza è che NON viene risolta, ma scartata e convertita in
SELECT * FROM T1
Questo significa che MySQL spara l'intera tabella a JET, che poi in LOCALE applica la WHERE... direi un vero spreco di risorse.
Le Query poi che fanno capo a Combo o ListBox potrebbero dare risultai migliori se fossero Query_PT, readOnly e risolte direttamente dal server senza il passaggio per l'interprete JET.
Quindi nelle maschere è meglio usare la proprietà FILTER per introdurre criteri, in quanto lo stesso viene risolto ClientSide ed inviato sepratamente al Server già elaborato, ottimizzando soprattutto il traffico dati.
Non dimenticare poi l'uso dei PARAMETERS... sconosciuti per la maggior parte, ma in questi casi salvano la vita, anche perchè le Maschere ed i Controlli DataBound possono essere associati non solo con RowSource o RecordSource, ma anche con il Recordset... che appunto estratto dall'utilizzo dei Parameters migliora le cose.
Il tutto richiede un po di strutturazione.