Question

与MediaWiki 1.31一样，没有扩展来批量删除垃圾邮件用户（仅manual merge & delete）。我们将通过MySQL删除用户，但是警告说此方法可能会由于引用表而破坏您的数据库。删除用户表/行时，是否有方法确保没有损坏引用？有什么经验或建议吗？

Answer 1

您是否尝试过以下操作：https://www.mediawiki.org/wiki/Manual:RemoveUnusedAccounts.php？

这是一个内置的密码，可以毫无问题地删除未使用的帐户。阅读上面链接中的说明。

Answer 2

今天，我面对的是旧版Mediawiki 1.23的问题，并进行了一些搜索。

根据以上信息，我做了一些实验。

首先，我想对损失进行一点评估：

外部链接

select  count(*) from externallinks

select convert(el_to using utf8) as href 
from externallinks l

那里有大约150.000个外部链接

SQL查询以了解有关用户的信息

select 
  convert(user_name using utf8) as name,
  convert(user_touched using utf8) as time,
  user_editcount 
from user 
order by 2 desc

就我而言，所有垃圾邮件用户都是在同一时间段创建的。

具有页，表，文本和用户表的联接的SQL查询。

select 
  convert(u.user_name using utf8) as username,
  p.page_id,
  convert(p.page_title using utf8) as pagetitle,
  r.rev_user as userid,
  convert(t.old_text using utf8) as text
from page p
inner join revision r
  on p.page_id=r.rev_page
inner join user u
  on r.rev_user=u.user_id  
inner join text t
  on r.rev_text_id=t.old_id

SQL查询以查找每个用户的修订数量：

select count(*),u.user_id,convert(u.user_name using utf8) as username
from revision r
inner join user u
on r.rev_user=u.user_id
group by 2
order by 1 desc

在我的情况下，所有“好”页面仅由一个用户使用user_id = 1创建，因此我可以通过以下方式评估损坏：

select count(*) as textcount from text where old_id in (select rev_text_id from revision where not rev_user in (1));

结果使我获得了超过一百万次点击，这意味着最好采用逐步方式删除：

select count(*) as textcount from text where old_id in (select rev_text_id from revision where not rev_user in (1)); 
set autocommit=0;
start transaction;
delete from text where old_id in (select rev_text_id from revision where not rev_user in (1)) limit 2000; 
commit;

请不要因为2000的限制已经导致大约2分钟的运行时间。所以我不得不运行上面的SQLStatement大约250次，每次等待2分钟...

如果遇到删除时间问题，可以考虑以下提示：

How can I improve DELETE FROM performance on large InnoDB tables?

您可以通过以下方式查看我们的餐桌状态：

show table status from <wiki-databasename>;

在我的情况下，表使用的是INNODB。

我尝试将innod_buffer_pool_size增加到128 MByte，但这没有积极作用。删除仍然很慢。

我仍然会尝试通过删除其中的相关行来完成此工作并按我的方式进行操作

外部链接
修订
页面

我还检查了/ var / lib / mysql /中的文件。由于我在每个表上都有innodb文件，因此我看到相当多的表变得非常大。

所以调查了

https://www.percona.com/blog/2013/09/25/how-to-reclaim-space-in-innodb-when-innodb_file_per_table-is-on/

并开始

optimize table text

花了8个小时才能完成。

幸运的是，在我看来，它实际上不是生产Wiki。我只想检查这种方法的可行性，看来它很大程度上取决于所涉及的行数。

基于API和维护的方法可能会更有效，具体取决于具体方案。

通过mysql删除MediaWiki垃圾用户

2 个答案: