|
假设我们有一个带有MySQL 5.6数据库的Web论坛应用程序,可由许多用户全天候访问.现在有一个这样的表用于发送给用户的通知的元数据.
| notifications | CREATE TABLE `notifications` (
`id` bigint(20) unsigned NOT NULL AUTO_INCREMENT,
`user_id` bigint(20) unsigned NOT NULL,
`message_store_id` bigint(20) unsigned NOT NULL,
`status` varchar(10) COLLATE ascii_bin NOT NULL,
`sent_date` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
PRIMARY KEY (`id`),
KEY `user_id` (`user_id`,`sent_date`)
) ENGINE=InnoDB AUTO_INCREMENT=736601 DEFAULT CHARSET=ascii COLLATE=ascii_bin |
该表有100万行.使用此表,某个message_store_id由于某种原因突然变得无效,我打算用一个删除语句删除带有该message_store_id的所有记录
DELETE FROM notifications WHERE message_store_id = 12345;
由于此消息已发送给这么多用户,因此该单个语句会影响表的10％.同时,成千上万的用户一直在访问这些通知表,因此索引必须存在.显然,索引重新创建在删除记录时非常昂贵,所以我害怕这样做,并通过最大限度地减少服务器资源来减少时间.但是,如果我删除索引,删除记录然后再次添加索引,我必须关闭数据库一段时间,不幸的是我们的服务是不可能的.
我希望MysqL 5.6不是那么愚蠢,这个单一语句可以杀死数据库,但我想这很可能.我的问题是,对于像这样的案例,索引娱乐真的是致命的吗？如果是这样,这个操作有什么好的策略,不要求我停止维护数据库吗？ 解决方法: 根据应用程序的详细信息,您可以使用许多技巧/策略.
>如果您打算定期执行这些操作(例如,它不是一次性操作),并且在message_store_id中几乎没有不同的值,则可以使用分区.按message_store_id的值进行分区,事先创建X分区(其中X是id值的一些合理上限),然后您可以通过截断该分区立即删除该分区中的所有记录.几毫秒.缺点：message_store_id必须是主键的一部分.注意：您必须事先创建分区,因为我上次使用它们时,alter table add partition重新创建了整个表,这对大型表来说是一场灾难.
>即使alter table截断分区不适合您,您仍然可以从分区中受益.如果在分区上发出DELETE,则通过提供相应的where条件,该DELETE操作不会影响/锁定表的其余部分.
>删除记录而不锁定DB太长时间的替代方法：
while (true) {
// assuming autocommit mode
delete from table where {your condition} limit 10000;
// at this moment locks are released and other transactions have a chance
// to do some stuff.
if (affected rows == 0) {
break;
}
// This is a good place to insert sleep(5) to give other transactions
// more time to do their stuff before the next chunk gets deleted.
}
（编辑：北几岛）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
