Thanks for the reply.
Tables ARE locked to updates during reads - so if you try to update
a table while another thread is performing a query on that table,
the update is stalled until that query ends.
However, I think MySQL separates the actual execution of the
query from sending the results of the query to the client.
I wrote a little script yesterday to investigate this. The script
performed a "select" query, and then pulled the result rows one at a
time with a 20 second delay between fetches. While this was happening,
I updated the same table with no delay.
This isn't convincing however - the (Perl) library in my script
might well have buffered the results on the client-side and might
have already pulled all the results onto the client before my
I need to rerun the experiment with a multi-megabyte dataset.
On Tue, 2003-05-20 at 18:00, Ryan R. Tharp wrote:
> I would agree that it doesn't lock the table on reads unless you explicitly
> stated so. I don't think there's a limit unless you query required to create
> a temporary table ( can find this out by using explain command on the query
> in question) which is limited to available disk space.