2009-05-08 9 views
2

J'ai une requête très simple (trois où conditions, deux égales, une entre) d'une seule table et dans MySQL Query Browser la requête prend moins d'une demi-seconde à exécuter, renvoyant 8300 enregistrements. Si je cours exactement la même requête en utilisant MySQL Data Connector (en fait, un wrapper OLEDB), cela prend environ 35 secondes.Pourquoi MySQL Data Connector prend-il beaucoup plus de temps que MySQL Query Browser?

Le moteur utilisé est MyISAM (si cela est important). J'utilise Visual Studio 2008 (aussi, si cela est important). Edit: Utilisation de MySQL Data Connector 5.2.5. Edit, edit: Passer à MySQL Data Connector 6.0.3 (le dernier) l'a réduit à 29 secondes.

La requête est:

select drh_data.reading_time, drh_data.raw_value, drh_data.float_value, drh_data.data_quality 
from drh_data 
where drh_data.site_id=202 
and drh_data.device_id=7 
and reading_time between '2009-04-08 11:15:01' and '2009-05-08 11:15:02' 
order by drh_data.reading_time desc; 

Toutes les idées? Mise à jour: J'ai finalement commencé à vérifier l'utilisation du processeur (comme suggéré par un répondeur) et j'ai constaté que 50% du temps CPU est utilisé par mon application. La boîte VirtualPC qui exécute MySQL (dans CentOS) a eu 0% pendant ces 20 secondes (environ), donc le problème est du côté du client. J'ai également couru un Explain sur la question, qui est revenu avec ce qui suit:

id select_type table type possible_keys        key        key_len  ref  rows Extra 
1 SIMPLE drh_data range PRIMARY,idx_site_device_reading_receive  idx_site_device_reading_receive 11     7674 Using where 

Je suis tapé ici. Est-ce que quelqu'un a des idées pour résoudre cela? Je suis sur le point de devoir démanteler les sélections via LIMIT, mais je ne pense pas que je devrais le faire.

+0

Oh, adorable. Cela s'est avéré être un problème DataGridView, pas un problème de requête MySQL. Le chargement de DataGridView a pris beaucoup plus de temps car DataGridView a dû redimensionner chaque cellule dans une rangée chaque fois qu'une ligne a été ajoutée, car j'ai défini AutoSizeRowsMode sur AllCells. Il est maintenant à 4 secondes, ce qui est beaucoup plus raisonnable. –

Répondre

1

Je suggère de vérifier ce qui fait le travail pour ces secondes (utilisation du processeur), est-ce mysql ou est-ce votre code ou autre chose. Vous pouvez également utiliser EXPLAIN pour voir ce qui se passe dans l'un ou l'autre cas et les comparer.

+0

Enfin en mesure de tester: l'utilisation du processeur est à 50%, entièrement sur mon application (je cours réellement MySQL sur un VirtualPC sur la même boîte, donc je serais en mesure de voir si cela fonctionne aussi bien, et il isn 't, du tout). Expliquer montre qu'il s'agit d'un select_type SIMPLE, la clé qu'il utilise et la colonne Extra indique "Using where". Je ne sais pas quoi d'autre à regarder maintenant, cependant. –

+0

Bien que cela ne réponde pas exactement à la question posée, cela m'a conduit dans la bonne direction, ce qui est assez bon pour moi. –

1

J'ai rencontré ce problème avant d'utiliser ADO.NET par rapport à l'Analyseur de requêtes SQL Server. Lorsque nous avons exécuté une requête à partir de Query Analyzer, la requête a été exécutée en secondes, lorsque nous l'avons exécutée à partir de notre application Web, elle prenait plus de 2 minutes. Pour une raison quelconque, l'application d'index à la table semblait accélérer la connexion de données entre notre application et la base de données. Je ne connaissais pas les différences opérationnelles entre MySQL et SQL Server, mais une autre chose qui semblait se produire dans notre cas était que le cache d'exécution était rempli et que l'exécution de tous les plans d'exécution non reliés était ralentie. Nous avons implémenté un travail hebdomadaire qui efface ce cache.

+0

Je vais vérifier ça quand je serai de retour au travail. Peut-être y a-t-il un moyen de lui dire de ne pas toucher le cache d'exécution (quelque chose comme SQL_NO_CACHE lors d'une sélection)? –

+0

SQL_NO_CACHE l'a réduit à environ 14 secondes, ce qui est mieux, mais toujours pas génial. –