From http://en.wikipedia.org/wiki/Lock_(computer_science)#Types

lock overhead: The extra resources for using locks, like the memory space allocated for locks, the CPU time to initialize and destroy locks, and the time for acquiring or releasing locks. The more locks a program uses, the more overhead associated with the usage.

I’m not sure where you got the absolute statement “waiting for a lock does not use any CPU”. This sounds like something a textbook or CS professor would say. In UN*X, the “wait” state technically does not use CPU, but that’s not the same as saying creating, maintaining, and destroying locks has no overhead. It’s just not true.

http://bugs.mysql.com/bug.php?id=49047

When there are many locks on a single row in InnoDB, CPU usage will get very large due to
deadlock checking. This is due to the fact that in this case, the complexity will grow at
exponential time.

And http://www.mysickql.com/?p=78

What I discovered with kind of great surprise (I know Baron, it’s in your book) that some resources in MySQL uses just one Mutex semaphore, which, in high concurrency environments like web sites, can really put your monster server on its knees.

I don’t think transactions getting serialized due to locks is a bad thing. Having multiple people update the same row at once is exactly what I do NOT want.