我的MySQL服务器随机停止工作，检查日志文件后发现：
190622 23:45:10 [Note] InnoDB: innodb_empty_free_list_algorithm has been changed to legacy because of small buffer pool size. In order to use backoff, increase buffer pool at least up to 20MB.
***
Version: '10.0.31-MariaDB' socket: '/var/run/mysql/mysql.sock' port: 3306 SLE 12 SP1 package
2019-06-22 23:45:13 7f3013fff700 InnoDB: Assertion failure in thread 139844470699776 in file trx0purge.cc line 698
InnoDB: Failing assertion: purge_sys->iter.trx_no <= purge_sys->rseg->last_trx_no
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
190622 23:45:13 [ERROR] mysqld got signal 6 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
To report this bug, see https://mariadb.com/kb/en/reporting-bugs
We will try our best to scrape up some info that will hopefully help
diagnose the problem, but since we have already crashed,
something is definitely wrong and this may fail.
Server version: 10.0.31-MariaDB
key_buffer_size=134217728
read_buffer_size=131072
max_used_connections=0
max_threads=153
thread_count=0
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 467015 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
因此，我在Google上搜索了一堆，以找出如何诊断可能已损坏的内容。我做了通常的innodb_force_recovery = 3，这是允许服务运行的最低层。
这时我运行了mysqlcheck --all-databases -u root -p，实际上确实为我提供了一个nextcloud数据库中的损坏的表。我已经多年没有使用nextcloud了，所以我决定通过正常登录mysql并运行DROP DATABASE nextcloud;来删除整个数据库，这样做很好。
现在，当我运行mysqlcheck时，它会很好地列出所有数据库：
mysql.column_stats OK
mysql.columns_priv OK
mysql.db OK
mysql.event OK
mysql.func OK
mysql.gtid_slave_pos OK
mysql.help_category OK
mysql.help_keyword OK
mysql.help_relation OK
mysql.help_topic OK
mysql.host OK
mysql.index_stats OK
mysql.innodb_index_stats OK
mysql.innodb_table_stats OK
mysql.plugin OK
mysql.proc OK
mysql.procs_priv OK
mysql.proxies_priv OK
mysql.roles_mapping OK
mysql.servers OK
mysql.table_stats OK
mysql.tables_priv OK
mysql.time_zone OK
mysql.time_zone_leap_second OK
mysql.time_zone_name OK
mysql.time_zone_transition OK
mysql.time_zone_transition_type OK
mysql.user OK
territory.points OK
wordpress.wp_commentmeta OK
wordpress.wp_comments OK
wordpress.wp_links OK
wordpress.wp_options OK
wordpress.wp_postmeta OK
wordpress.wp_posts OK
wordpress.wp_term_relationships OK
wordpress.wp_term_taxonomy OK
wordpress.wp_termmeta OK
wordpress.wp_terms OK
wordpress.wp_usermeta OK
wordpress.wp_users OK
所以我继续删除innodb_force_recovery = 3并尝试重新启动mysql服务。遗憾的是，它只能在第3层恢复上运行。在这一点上我有点迷茫。我下一步应该去哪里寻找导致腐败的原因？哦，mysql日志保持完全相同，因此没有变化。
我不会特别担心是否丢失数据，因为我关心的唯一数据库是territory。显然我想保留数据，但是如果我唯一的选择是以某种方式从mysql开始半刷新，那么我会这样做，但前提是这是我的最后选择。