docker 安装mysql5.6.29_docker 安装 MySQL，执行 optimize 后容器挂了

问题描述

我用 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.

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