mysql replication中耗时更新操作阻塞整个库更新的问题如何解决

虽然4.0后replication的slave已经分成了relay和update两个线程，至少bin-log的读取不会被阻塞住了，但是update线程还是以库为单位顺序执行的，这时一旦有个耗时update操作，尽管只涉及一个表，但是整个slave库的更新都会被阻塞住。5.0的文档中还没有看到这个update线程细化到以表为单位执行的迹象。
大家尝试过什么解决办法没有。

try this:

http://code.google.com/p/google-mysql-tools/w/list

The patches include a few big features and many enhancements. The big features are:
SemiSyncReplication - block commit on a master until at least one slave acknowledges receipt of all replication events.
MirroredBinlogs - maintain a copy of the master's binlog on a slave
TransactionalReplication - make InnoDB and slave replication state consistent during crash recovery
UserTableMonitoring - monitor and report database activity per account and table
InnodbAsyncIo - support multiple background IO threads for InnoDB
FastMasterPromotion - promote a slave to a master without restart

Other enhancements include:
LosslessFloatDump - support dump and restore of float/double without loss of precision
Use 8X less memory for account and table privileges
Use fastest compression rather than the default level for client/mysqld networking
InnodbSampling - control the number of leaf blocks sampled for optimizer statistics
InnodbStatus - display more statistics in show innodb status
Reduced number of calls to fsync when the InnoDB background IO thread is active
Changed InnoDB to recover when InnoDB and MySQL data dictionaries are inconsistent
NewSqlFunctions - functions for checksums and floating point to string conversion
Backported START SLAVE UNTIL
Sort float columns with the order: -INF < negative < 0 < positive < +INF < NaN
Change long_query_time to be dynamic and log all queries that run for greater than or equal this number of seconds rather than greater than.
Count connection attempts tha are denied because of max_connections and display the count as denied_connections
MoreLogging - log actions done on specified tables and SUPER users
rpl_always_enter_innodb boosts the priority of the slave SQL thread (for replication) in InnoDB by making it ignore the InnoDB concurrency limits
rpl_event_buffer_size sets the fixed size buffer that is allocated in the master for each connected slave. The buffer is used for replication events smaller than the buffer. This reduces memory allocation done to copy replication events from the master.
Backported sync-binlog
Added reserved_super_connections to reserve the final N connections for users with the SUPER privilege
NewShowStatus - many new variables in SHOW STATUS

貌似没有针对我所说问题的patch

相当于把整个库都锁了？

在我看来这只是连带把master也给一起麻醉了吧

补充一下，在我看来，最理想的解决方案应该是slave以表为单位，为每个表维护一个fifo update queue，一个表被锁了就由它自己排队去，其他的该怎么玩还怎么玩，才是正道。

最不济，我们可以配置一个只记录了update动作信息的replication，然后在slave端起一个自己的进程，为每个表维护一个queue，自己来做更新动作，只是这样基本上活就都自己干了

难道其他人没有遇到过类似问题？我估摸着早就该有类似的patch了

slave 是库为单位，没有到表，而且replicate的时候，其实是一个进程，一个进程的运行，而不是几个进程同时。

innodb的update是行级锁定，如果你仅仅只是update几条记录，根本不会出现lock的问题。如果你update很多很多记录，那么你应该考虑一下你这样的操作是否合理。

你确认？难道我们用的不是同一家公司出的mysql不成。
这里说的是mysql replication中slave端的后台update exec线程（纠正以下上面某个帖子，是线程，不是进程）的执行模式，我没有讨论mysql update动作本身的锁定问题。

如果仅仅是update单条或者几条记录，请你告诉我，为什么会耗时？