检查 mysql 数据库的启动时间linux 系统中的 systemd 和 mysqld_safe 会在 mysqld 进程 crash 后自动重新启动 mysql 的服务，需要注意的是使用 kill -9 杀死 mysqld 进程系统会自动重新启动，而只使用 kill 命令则不会重新启动，因为执行 kill 命令，系统会发送一个 sigterm 信号给 mysqld，mysql 数据库会正常关闭，日志中会出现类似下面的记录：
2020-10-26t09:06:48.435181z 0 [system] [my-010910] [server] /usr/sbin/mysqld: shutdown complete (mysqld 8.0.19)  mysql community server - gpl.
mysql 数据库 crash 后都会重新启动，因此我们有时可能不知道 mysql 数据库已经 crash 过了，但我们可以从mysql数据库启动时间上找到线索，下面介绍四种检查 mysql 数据库启动时间的方法。
检查 mysql 服务状态scutech@scutech:~$ service mysql status● mysql.service - mysql community server loaded: loaded (/lib/systemd/system/mysql.service; enabled; vendor preset: enabled) active: active (running) since wed 2020-10-21 05:54:18 ndt; 4 days ago process: 774 execstart=/usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid (code=exited, status=0/success) process: 708 execstartpre=/usr/share/mysql/mysql-systemd-start pre (code=exited, status=0/success) main pid: 791 (mysqld) tasks: 27 (limit: 2328) cgroup: /system.slice/mysql.service └─791 /usr/sbin/mysqld --daemonize --pid-file=/var/run/mysqld/mysqld.pid
显示 mysql 数据库已经运行 4 天多。
检查 mysql 中的 uptime 状态mysql> show global status like 'uptime';+---------------+--------+| variable_name | value |+---------------+--------+| uptime | 428334 |+---------------+--------+1 row in set (0.32 sec)
这个值是以秒为单位，下面换算成以天为单位是 4 天多。
mysql> select 428334/60/60/24;+-----------------+| 428334/60/60/24 |+-----------------+| 4.957569444444 |+-----------------+1 row in set (0.01 sec)
查询 uptime 状态的另一种方法是使用 mysqladmin version 或在 mysql 客户端里用 “\s” 进行查询。
使用 ps 检查进程启动时间使用 ps 命令查询发现 mysqld 启动了4天23小时3分种54秒
scutech@scutech:~$ ps -eo pid,user,args,etime|grep mysqld 791 mysql /usr/sbin/mysqld --daemoniz 4-23:03:54
检查 mysql 日志找关键字 “ready for connections”，可以查到启动信息。
2020-10-21t08:24:18.986765z 0 [note] /usr/sbin/mysqld: ready for connections.
version: '5.7.28-log' socket: '/var/run/mysqld/mysqld.sock' port: 3306 mysql community server (gpl)
mysql 数据库 crash 的常见原因mysql 数据库 crash 的最常见原因有两个，一个是 mysql 的 bug ， 另一个是 mysql 申请系统资源失败或内存泄漏。
mysql 的 bugmysql数据库 crash 的最常见的一个原因当然是 mysql 的bug。95% 的 bug 都是和具体的 sql 相关，通常是 mysql crash 前执行的最后一个 sql 有问题，因此定位 bug 时应打开 general query log ，根据最后一个 sql 来查找线索。
当你确定了 crash 的原因后，应该检查一下 mysql 的 bug 库（https://bugs.mysql.com），通常采用 advanced search，看看有没有类似的问题。如果你找到了可能与你相关的 bug，确认它是否修复了。如果已经修复了，那么把 mysql 升级到 bug 已经修复的版本。
在每个版本的 release notes 里面有一节 bugs fixed ，可以查到修复的 bug 。
mysql 申请系统资源失败或内存泄漏内存不足或 mysql 申请系统资源失败外都会造成 mysql 崩溃，例如磁盘空间满了，磁盘上的文件 corrupt 等。此时需要定位 crash 的根本原因有下面几种方法：
仔细阅读 mysql 的错误日志，这个日志里面的一些程序调试信息看起来很让人困惑，但静下心来仔细看，很多时候会找到线索；
打开 general query log ，找到最后一个 sql 访问的表或索引，检查这个表或索引，如果有问题就重建，通常可以解决问题。
使用 strace、pstack、pmap、gdb 分析 mysqld 的代码，可能需要打开 core dump；
使用 cmake 的选项 -dwith_debug=1 重新编译 mysqld，然后运行重新编译后的 mysqld，查看 trace 文件、error log 进行排错。
mysql 内存占用的计算全局内存
innodb_buffer_pool_size innodb_log_buffer_size thread_cache_size table_open_cache table_definition_cache key_buffer_size
线程内存
binlog_cache_size thread_stack
单次操作内存
join_buffer_size read_buffer_size read_rnd_buffer_size tmp_table_size sort_buffer_size
计算公式
mysql 8 中最大内存占用参考值计算公式：
select ( @@innodb_buffer_pool_size + @@innodb_log_buffer_size + @@key_buffer_size + @@max_connections * (@@binlog_cache_size + @@thread_stack + @@read_buffer_size + @@read_rnd_buffer_size + @@sort_buffer_size + @@join_buffer_size + @@tmp_table_size ) ) / 1024 /1024 as max_mem_mb;
innodb_buffer_pool_size
key_buffer_size
max_connections*(sort_buffer_size+read_buffer_size+binlog_cache_size)
max_connections*2mb
临时解决可以使用下面的命令释放缓存：
echo 1 > /proc/sys/vm/drop_caches
0：0是系统默认值，默认情况下表示不释放内存，由操作系统自动管理
1：释放页缓存
2：释放dentries和inodes
3：释放所有缓存
从长远看还是要修改对应的参数进行解决。
mysql 客户端的内存泄漏mysql 客户端的内存泄漏时通常会有下面的提示
mysql: out of memory at line 42, 'malloc.c'
mysql: needed 8136 byte (8k), memory in use: 12481367 bytes (12189k)
error 2008: mysql client ran out of memory
这通常是客户端收到的返回结果集太大造成的，解决办法有两种：
检查正在运行的 sql ，看看您真的需要这么大的返回结果集吗？
允许 mysql 时加上 --quick 选项，这会减少客户端单次收到的返回集，但会增加 mysqld 的负载。
以上就是mysql数据库崩溃的常见原因和解决方法是什么的详细内容。