On Friday 20 July 2001 14:00, Steven Roussey wrote:
> > Locked table should not crash a server !!
> 
> Oh.. I only meant in the cascade sense: Locked Table -> Queries waiting ->
> Threads fill up -> Run out of memory ->  Crash

One thing to remember about row vs table level locking is that any query that 
locks the table for long enough to cause trouble with MyISAM is also likely 
to lock enough rows to cause trouble with a row level locking handler. In 
other words, row level locking will not fix the problem of poorly optimized 
query. 

A lot of times MySQL gets unfair blame for failing to perform due to table 
locking simply because it is an easy escape route to explain to the 
boss/co-workers why the site went down. The truth of the matter in many cases 
( not in all, of course) is that the same query mix would have caused a 
similar combination of problems with page or row locks.

If you guys are running into problems with lock contention or poor 
performance for some other reason, I would recommmend that you spend some 
time investigating the matter and then, if you cannot understand/fix the 
problem, submit a test case/benchmark that will demonstrate it. What happens 
is that our hacker's pride gets hurt when somebody says MySQL is not good 
enough for their system and presents some code to prove it. Either or both of 
the two things are going to happen:

 * We will tell you how you can optimize your system
 * We will fix MySQL so that your system will do better

Do not underestimate the power of this. It does miracles - from what I have 
observed in the last year and half that I worked with MySQL AB, this has been 
one of the most significant drivers of development. Hard repeatable evidence 
of performance problems really gets under our skin and we cannot sleep until 
we get it out, especially Monty. We get a kick out of having our users tell 
us that after our suggested optimization, the system runs 10-100 times faster 
and now can handle the load. We just ike to make things better.

-- 
MySQL Development Team
For technical support contracts, visit https://order.mysql.com/
   __  ___     ___ ____  __ 
  /  |/  /_ __/ __/ __ \/ /   Sasha Pachev <[EMAIL PROTECTED]>
 / /|_/ / // /\ \/ /_/ / /__  MySQL AB, http://www.mysql.com/
/_/  /_/\_, /___/\___\_\___/  Provo, Utah, USA
       <___/                  

---------------------------------------------------------------------
Before posting, please check:
   http://www.mysql.com/manual.php   (the manual)
   http://lists.mysql.com/           (the list archive)

To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php

Reply via email to