最近博客服务器的mysql mysql经常崩溃，挂了，不过我发现了的时候，重启就好了。基本一周来一次
2016-09-20 15:17:04 13896 [Note] Event Scheduler: Loaded 0 events 2016-09-20 15:17:04 13896 [Note] /opt/lampp/sbin/mysqld: ready for connections. Version: '5.6.21' socket: '/opt/lampp/var/mysql/mysql.sock' port: 3306 Source distribution 2016-09-21 13:34:04 27385 mysqld_safe Number of processes running now: 0 2016-09-21 13:34:04 27385 mysqld_safe mysqld restarted 2016-09-21 13:34:07 0 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be r emoved in a future release. Please use the full name instead. 2016-09-21 13:34:07 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_time stamp server option (see documentation for more details). 2016-09-21 13:34:07 9883 [Note] Plugin 'FEDERATED' is disabled. 2016-09-21 13:34:08 9883 [Note] InnoDB: Using atomics to ref count buffer pool pages 2016-09-21 13:34:08 9883 [Note] InnoDB: The InnoDB memory heap is disabled 2016-09-21 13:34:08 9883 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins 2016-09-21 13:34:08 9883 [Note] InnoDB: Memory barrier is not used 2016-09-21 13:34:08 9883 [Note] InnoDB: Compressed tables use zlib 1.2.8 2016-09-21 13:34:08 9883 [Note] InnoDB: Using CPU crc32 instructions 2016-09-21 13:34:08 9883 [Note] InnoDB: Initializing buffer pool, size = 16.0M 2016-09-21 13:34:08 9883 [Note] InnoDB: Completed initialization of buffer pool 2016-09-21 13:34:08 9883 [Note] InnoDB: Highest supported file format is Barracuda. 2016-09-21 13:34:08 9883 [Note] InnoDB: The log sequence numbers 1522094162 and 1522094162 in ibdata files do not match the log sequence number 1523166498 in the ib_logfiles! 2016-09-21 13:34:08 9883 [Note] InnoDB: Database was not shutdown normally! 2016-09-21 13:34:08 9883 [Note] InnoDB: Starting crash recovery. 2016-09-21 13:34:08 9883 [Note] InnoDB: Reading tablespace information from the .ibd files... 2016-09-21 13:34:10 9883 [Note] InnoDB: Restoring possible half-written data pages 2016-09-21 13:34:10 9883 [Note] InnoDB: from the doublewrite buffer... 2016-09-21 13:34:12 27385 mysqld_safe mysqld from pid file /var/mysql/iZ25kan0n7aZ.pid ended
会不会是innodb_buffer_pool_size 设置的太高了，超过了你的机器内存，请尝试降低该内存配置。
使用innodb 最好还是根据机器修改默认配置哦。
mysql崩溃原因汇总
1.可能是mysql连接问题
2.服务器内存不够。
3.140109 11:26:10 InnoDB: Initializing buffer pool, size = 180.0M 如果你用innodb 这个值简直就不可想象啊！
多篇文章指向innodb 会导致崩溃。我的日志The InnoDB memory heap is disabled 似乎也显示了这个关键要素。
一个网友的解决方案
环境：512M内存的vps，mysql 5.6，搭了wordpress
问题：mysql能启动，wordpress一被访问，数据库就crash
尝试1：将innodb_buffer_pool_size=128M 改为5M，wp可以访问了，只是坚持不了多久还会down
尝试2：
调整以下参数至：
performance_schema_max_table_instances=600 table_definition_cache=400 table_open_cache=256
这时mysql启动后内存就只占用40–60M内存了
以下是5.6默认的设置，会占用至少400M的内存，可能是导致crash的原因
performance_schema_max_table_instances 12500 table_definition_cache 1400 table_open_cache 2000
尝试3：经过尝试2后，问题解决了。但一个月后随着文章的增多，数据库又crash掉，直接动态扩展了vps内存到1G 问题彻底解决
，我个人觉得，vps 1g，可能 innodb_buffer_pool_size 值可以调的小点。比如32M？
虽然你有1g内仓，然后innodb_buffer_pool_size =128M，但是其他也有内仓分配，比如
key_buffer = 64M
query_cache_size = 64M
tmp_table_size = 250M
总共加起来就不少了。另外你的服务器也不止mysql，还有别的服务要占内存。
以上只是我个人推测。。。
这个配置需要根据你目前机器的资源和产品的应用来做调整，我简单的看了一下，这个配置文件不是很好，default-storage-engine = innodb
事例几个需要优化
innodb_buffer_pool_size = 180M #通常为物理内存的50%，或者70-80%
tmp_table_size = 250M
max_heap_table_size = 20M #这两个选项的值最好是相等的。
只有cpu太高，那就要优化SQL了，另外估计你代码的严谨度不够，比如一些地方需要做合并请求，总不能点一次查询一次。
MYSQL innodb 的配置经验
innodb_buffer_pool_size
如 果用Innodb，那么这是一个重要变量。相对于MyISAM来说，Innodb对于buffer size更敏感。MySIAM可能对于大数据量使用默认的key_buffer_size也还好，但Innodb在大数据量时用默认值就感觉在爬了。 Innodb的缓冲池会缓存数据和索引，所以不需要给系统的缓存留空间，如果只用Innodb，可以把这个值设为内存的70%-80%。和 key_buffer相同，如果数据量比较小也不怎么增加，那么不要把这个值设太高也可以提高内存的使用率。
innodb_additional_pool_size
这个的效果不是很明显，至少是当操作系统能合理分配内存时。但你可能仍需要设成20M或更多一点以看Innodb会分配多少内存做其他用途。
innodb_log_file_size
对于写很多尤其是大数据量时非常重要。要注意，大的文件提供更高的性能，但数据库恢复时会用更多的时间。我一般用64M-512M，具体取决于服务器的空间。
innodb_log_buffer_size
默认值对于多数中等写操作和事务短的运用都是可以的。如 果经常做更新或者使用了很多blob数据，应该增大这个值。但太大了也是浪费内存，因为1秒钟总会 flush（这个词的中文怎么说呢？）一次，所以不需要设到超过1秒的需求。8M-16M一般应该够了。小的运用可以设更小一点。
innodb_flush_log_at_trx_commit （这个很管用）
抱怨Innodb比MyISAM慢 100倍？那么你大概是忘了调整这个值。默认值1的意思是每一次事务提交或事务外的指令都需要把日志写入（flush）硬盘，这是很费时的。特别是使用电 池供电缓存（Battery backed up cache）时。设成2对于很多运用，特别是从MyISAM表转过来的是可以的，它的意思是不写入硬盘而是写入系统缓存。日志仍然会每秒flush到硬 盘，所以你一般不会丢失超过1-2秒的更新。设成0会更快一点，但安全方面比较差，即使MySQL挂了也可能会丢失事务的数据。而值2只会在整个操作系统 挂了时才可能丢数据。
机器调整，我发现我的mysql内存设置的太小
innodb_buffer_pool_size = 16M
调成128M 试试2天
innodb_buffer_pool_size = 128M
结果mysql根本无法正常启动
改成32M 好了，试试2天，看看效果
9月22再次崩溃
2016-09-22 19:57:51 18258 mysqld_safe Number of processes running now: 0
2016-09-22 19:57:51 18258 mysqld_safe mysqld restarted
2016-09-22 19:57:53 0 [Warning] Using unique option prefix key_buffer instead of key_buffer_size is deprecated and will be removed in a future release. Please use the
full name instead.
2016-09-22 19:57:53 0 [Warning] TIMESTAMP with implicit DEFAULT value is deprecated. Please use --explicit_defaults_for_timestamp server option (see documentation for
more details).
2016-09-22 19:57:53 16464 [Note] Plugin 'FEDERATED' is disabled.
2016-09-22 19:57:54 16464 [Note] InnoDB: Using atomics to ref count buffer pool pages
2016-09-22 19:57:54 16464 [Note] InnoDB: The InnoDB memory heap is disabled
2016-09-22 19:57:54 16464 [Note] InnoDB: Mutexes and rw_locks use GCC atomic builtins
2016-09-22 19:57:54 16464 [Note] InnoDB: Memory barrier is not used
2016-09-22 19:57:54 16464 [Note] InnoDB: Compressed tables use zlib 1.2.8
2016-09-22 19:57:54 16464 [Note] InnoDB: Using CPU crc32 instructions
2016-09-22 19:57:54 16464 [Note] InnoDB: Initializing buffer pool, size = 32.0M
尽量的找到mysql崩溃的原因，如果实在没办法了。还有个办法，就是写个脚本来检查mysql是否挂了 请移步使用一个脚本监控mysql自动重启