我注意到，当请求执行时，我们的应用程序不会响应请求。 跑top似乎确定了问题的根源：
top - 13:54:25 up 1 day, 13:43, 2 users, load average: 1.02, 0.98, 0.83 Tasks: 110 total, 1 running, 109 sleeping, 0 stopped, 0 zombie Cpu(s): 11.9%us, 1.1%sy, 0.0%ni, 86.8%id, 0.0%wa, 0.0%hi, 0.0%si, 0.2%st Mem: 3145728k total, 2329220k used, 816508k free, 0k buffers Swap: 131072k total, 128164k used, 2908k free, 1585060k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 26073 mysql 20 0 397m 209m 3452 S 99.1 6.8 3:02.49 mysqld 16419 mailnull 20 0 9848 3288 2664 S 2.3 0.1 1:17.63 exim 2085 nobody 20 0 44312 10m 3436 S 1.3 0.3 4:50.98 litespeed 24727 nobody 20 0 320m 50m 41m S 0.3 1.7 0:06.86 lsphp5 26314 root 20 0 2428 1104 832 S 0.3 0.0 0:00.36 top
在我看来，mysql正在占用运行的整个CPU（99.1％）。 这意味着我们的一个核心是100％挂钩，而另外7个（7！）空闲在0％。
我知道，如果我们的表是InnoDB，负载将分布在核心之间。 它是否正确？
有没有办法在我们的表使用MyISAM的内核之间分配工作负载？
我完全看错了地方吗？ 尽pipe资源占用大的查询占用了一个CPU，但MySQL不应该利用其他CPU来进行单独的查询吗？ 或者，这是由我们使用MyISAM限制吗？
你对InnoDB的理解和负载分布在更多的内核上是错误的，但是很接近。
MyISAM表执行“基于表的locking”，这意味着任何locking表的查询都必须阻止所有其他需要获取锁的查询。
InnoDB对大多数操作使用“基于行的locking”，允许其他查询不需要locking确切的行并行继续。
一个单一的大型查询仍然只使用一个核心，不pipe是MyISAM还是InnoDB，但是多个查询碰到同一个表应该能够在不同的核心上同时执行，只要它们不被行级锁阻塞。