250G硬盘，2G内存，q8400的cpu，debian系统，mysql5.1.58，512M的buffer pool
在根据普通int索引，删除大量数据的时候（已经删了2个小时了DELETE FROM table_log_http WHERE time < xxx，time是int索引），我这时候，执行lock table t1，t2， write（30多个表（policy库），不包括table_log_http（log库））的时候，总是获取不到锁，超时，而并没有对这些表操作的其他进程（show processlist没有对policy库的其他操作）
这我应该怎么优化一下呢，这个问题出在哪呢？另外，硬盘灯常亮，除了数据库，没什么其他的磁盘读写非常频繁的操作了，但，数据库操作就是那个DELETE……
在根据普通int索引，删除大量数据的时候（已经删了2个小时了DELETE FROM table_log_http WHERE time < xxx，time是int索引），我这时候，执行lock table t1，t2， write（30多个表（policy库），不包括table_log_http（log库））的时候，总是获取不到锁，超时，而并没有对这些表操作的其他进程（show processlist没有对policy库的其他操作）
这我应该怎么优化一下呢，这个问题出在哪呢？另外，硬盘灯常亮，除了数据库，没什么其他的磁盘读写非常频繁的操作了，但，数据库操作就是那个DELETE……
lock table t1，t2， write
执行的结果是什么，有lock权限吗一个一个锁定试试
这个和你的DELETE操作没有关系了。
你尝试下把t1,t2的个数减少看看。一次封锁很多表，需要挨个去数据库请求，可能会很慢。
抱歉，今天才连上那个设备，因为我是5.1.58版，explain只能对select生效，所以我把delete替换为select *尝试了一下，用到索引了，然后，那个表有8259万行，然后每次删除的大概是8259/(60*24)行，所以其实也不多，不知道为什么会有这个问题……
lock权限肯定是有的，这个就是偶尔发生，现在看又没事了……然后，lock单表应该是可以的，因为，其他对单个表的大量写入和修改都是可以的，说明排它锁还是可以加上的，等再出现问题的时候再实际试一下lock语句整个单表吧……那个表有8259万行，然后每次删除的大概是8259/(60*24)行，其实也不多……
对了，现在没有那种长时间的delete语句了，然后，硬盘灯也正常了……
现在没有长时间的delete语句了，然后lock表也正常了，哎~~等再出现这个情况再说吧~~然后，lock单表应该是可以的，因为，其他对单个表的大量写入和修改都是可以的，说明排它锁还是可以加上的，等再出现问题的时候再实际试一下lock语句整个单表吧……
MyISAM和MEMORY表进行表级锁定，对BDB表进行页级锁定，对InnoDB表进行行级锁定
你这种情况 我在其它的数据库里面遇到过
类似于 out of locks
是你获取的最大的锁的值过高引起的
但楼主具体的原因我看还是找出来的好。有问题了就得找出他是什么原因产生的 。希望大牛们多多参与~~
thank you very much！！！
能不能说说当时是怎么解决的呢？
sp_configure "number of locks"
是这个值过低造成的 而导数据的时候产生了大量的锁 超过了number of locks 设置的值
设置大一点了 问题就解决了、
没看见有这个参数啊，有个max_write_lock_count，但他的解释是：“写锁达到一定数量后, 就不限制读锁, 允许一部分读锁进入”。您设置的是哪个参数？
了解了，sybase哈，貌似mysql里没见到类似的参数啊~~
确实考虑过，但在网上的测试说，如果是稍微大些的数据量，比如百万、千万级别，innodb应该有更好的性能的
我记在博客里了：http://blog.chinaunix.net/space.php?uid=26363964&do=blog&id=3088242
我看到我第一个锁表的操作在等待table_log_http的锁？（提示信息是这意思吗？），可他们之间并没有交叉，按说根本没必要等的……不理解，您帮忙看下行吗~~谢谢~~