> I suppose your test program connects, and loops the same query multiple
> times in the same session? (Just to rule out connect/disconnect
Of course. I also run the same query multiple times, to eliminate caching
issues. Performance on successive iterations is the same as on the first.
It is bizarre how the query that asks for 33 rows on an indexed field
works fine, yet the query that asks for 1 row on the primary key performs
> What are your timings if you run your client on the SCO box?
mysql simply reports a query time of 10ms or less (0.01s). Of course,
this doesn't have any network overhead.
> If all your queries are instantaneous
They're not - one Windows box (the 98SE one) reports a query time of
180ms and a data fetch time of 10ms, while the Win2000 box reports the
opposite (query 10ms, fetch 180ms)
> I'd say start dumping packets on the network.
I'd agree, but I'm confused as to why a different query (that requests
more data; 33 rows vs 1) can reliably execute and fetch in 10ms on all
machines? The behaviour is completely reproducible: SELECT (1 record) ON
PRIMARY KEY = slow (200ms), SELECT (lots of records on indexed field) =
> 200ms sounds a lot like Nagle's Algorithm kicking in (which
> shouldn't happen assuming the mysql libs are written right).
Indeed, I wouldn't have thought they'd have included that! Isn't
Nagle restricted to telnet? But anyway, not all queries perform