mysql - 通过 mysql 删除 mediawiki 垃圾邮件用户

Question

与 MediaWiki 1.31 一样，没有用于批量删除垃圾邮件用户的扩展(仅 manual merge & delete)。我们会通过 MySQL 删除用户，但是有警告说这种方法可能会因为引用表而破坏你的数据库。删除用户表/行时，有没有办法确保没有引用受到损害？有什么经验或建议吗？

Answer 1

今天我遇到了旧 Mediawiki 1.23 的问题，并进行了一些搜索。

• > MediaWiki Manual:Database layout
• > Database Schema Diagramm
• > Manual:Page table - deleting pages with their relationships in text and revision table

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

首先我想评估一下损失:

外部链接

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

在我的案例中，所有 SPAM 用户都在同一时间段内创建。

通过页面、修订、文本和用户表进行联接的 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));

结果给我超过 50 万次点击，这意味着最好逐步删除:

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 和维护的方法可能更有效。