docker 安装 MySQL，执行 optimize 后容器挂了

Question

问题描述

我用 docker 安装了 MySQL，一般的操作也没有问题，但是当我删除了一部分数据想要优化存储时，执行完 optimize 命令后，容器意外的关闭了，我尝试了两次，都遇到相同的情况，直到第三次，居然成功的执行了。我想知道这究竟是什么原因

问题出现的平台版本及自己尝试过哪些方法

Ubuntu 18.10 CPU 8代i5 内存 8G
docker 18.06 MySQL 5.6

相关代码

// 这是 docker 的日志

2018-11-29T07:57:53.748628846Z Main thread process no. 1, id 140634823509760, state: enforcing dict cache limit
2018-11-29T07:57:53.748638650Z Number of rows inserted 0, updated 0, deleted 500000, read 1000025
2018-11-29T07:57:53.748648265Z 0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
2018-11-29T07:57:53.748657822Z ----------------------------
2018-11-29T07:57:53.748667432Z END OF INNODB MONITOR OUTPUT
2018-11-29T07:57:53.748677298Z ============================
2018-11-29T07:58:01.330201271Z InnoDB: ###### Diagnostic info printed to the standard error stream
2018-11-29T07:58:01.330256078Z InnoDB: Error: semaphore wait has lasted > 600 seconds
2018-11-29T07:58:01.330271953Z InnoDB: We intentionally crash the server, because it appears to be hung.
2018-11-29T07:58:01.330283530Z 2018-11-29 07:58:01 7fe819b2e700  InnoDB: Assertion failure in thread 140634840295168 in file srv0srv.cc line 1757
2018-11-29T07:58:01.330294135Z InnoDB: We intentionally generate a memory trap.
2018-11-29T07:58:01.330304101Z InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
2018-11-29T07:58:01.330314217Z InnoDB: If you get repeated assertion failures or crashes, even
2018-11-29T07:58:01.330353114Z InnoDB: immediately after the mysqld startup, there may be
2018-11-29T07:58:01.330364784Z InnoDB: corruption in the InnoDB tablespace. Please refer to
2018-11-29T07:58:01.330375697Z InnoDB: http://dev.mysql.com/doc/refman/5.6/en/forcing-innodb-recovery.html
2018-11-29T07:58:01.330385931Z InnoDB: about forcing recovery.
2018-11-29T07:58:01.330395975Z 07:58:01 UTC - mysqld got signal 6 ;
2018-11-29T07:58:01.330408020Z This could be because you hit a bug. It is also possible that this binary
2018-11-29T07:58:01.330419073Z or one of the libraries it was linked against is corrupt, improperly built,
2018-11-29T07:58:01.330428760Z or misconfigured. This error can also be caused by malfunctioning hardware.
2018-11-29T07:58:01.330438247Z We will try our best to scrape up some info that will hopefully help
2018-11-29T07:58:01.330448883Z diagnose the problem, but since we have already crashed, 
2018-11-29T07:58:01.330458865Z something is definitely wrong and this may fail.
2018-11-29T07:58:01.330468227Z 
2018-11-29T07:58:01.330477549Z key_buffer_size=8388608
2018-11-29T07:58:01.330486914Z read_buffer_size=131072
2018-11-29T07:58:01.330496185Z max_used_connections=3
2018-11-29T07:58:01.330506383Z max_threads=151
2018-11-29T07:58:01.330517415Z thread_count=1
2018-11-29T07:58:01.330527401Z connection_count=1
2018-11-29T07:58:01.330537193Z It is possible that mysqld could use up to 
2018-11-29T07:58:01.330547634Z key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 68108 K  bytes of memory
2018-11-29T07:58:01.330557770Z Hope that's ok; if not, decrease some variables in the equation.
2018-11-29T07:58:01.330567551Z 
2018-11-29T07:58:01.330578014Z Thread pointer: 0x0
2018-11-29T07:58:01.330587976Z Attempting backtrace. You can use the following information to find out
2018-11-29T07:58:01.330598936Z where mysqld died. If you see no messages after this, something went
2018-11-29T07:58:01.330609343Z terribly wrong...
2018-11-29T07:58:01.330624111Z stack_bottom = 0 thread_stack 0x40000
2018-11-29T07:58:01.332006805Z mysqld(my_print_stacktrace+0x2c)[0x55da4cb9d05c]
2018-11-29T07:58:01.332397783Z mysqld(handle_fatal_signal+0x4b1)[0x55da4c93ab51]
2018-11-29T07:58:01.332416149Z /lib/x86_64-linux-gnu/libpthread.so.0(+0x110c0)[0x7fe82f3e90c0]
2018-11-29T07:58:01.332426557Z /lib/x86_64-linux-gnu/libc.so.6(gsignal+0xcf)[0x7fe82df85fff]
2018-11-29T07:58:01.332529820Z /lib/x86_64-linux-gnu/libc.so.6(abort+0x16a)[0x7fe82df8742a]
2018-11-29T07:58:01.333542705Z mysqld(+0x7a6e98)[0x55da4cc81e98]
2018-11-29T07:58:01.333555593Z /lib/x86_64-linux-gnu/libpthread.so.0(+0x7494)[0x7fe82f3df494]
2018-11-29T07:58:01.333701818Z /lib/x86_64-linux-gnu/libc.so.6(clone+0x3f)[0x7fe82e03bacf]
2018-11-29T07:58:01.333737718Z The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
2018-11-29T07:58:01.333749000Z information that should help you find out what is causing the crash.

希望有人能帮我解决一下，是因为内存不够了吗？还是其他原因？我要怎样防止这种情况？

Answer 1

set global innodb_adaptive_hash_index=0;
看看还会出现重启么