下载mysql怎么那么慢 为什么mysql下载失败

MySQL速度变慢，怎么办

MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。

创新互联建站是一家专业提供砚山企业网站建设,专注与做网站、网站建设、HTML5、小程序制作等业务。10年已为砚山众多企业、政府机构等服务。创新互联专业网站制作公司优惠进行中。

如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：

1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。

临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。

load MySQL极慢，为什么

可能是手机的机身内存不足了，可以进行下内存清理

可以使用腾讯手机管家的内存清理功能来进行清理

先通过垃圾扫描来清理掉手机上的垃圾和软件的缓存

之后进行深度清理，把一些文件垃圾、缓存文件、安装包之类的垃圾也清理掉

linux服务器下mysql启动慢，怎么解决

0 先了解主机和数据库的环境

#主机

内存多大，为了看有多少剩余能为mysql留出多少来：free

资源使用情况，看负载情况，重点看空闲 CPU百分比(带 xx% id)：top

#mysql

看mysql数据文件多大：du -c -s /var/lib/mysql

1 初步调整（最主要的）

# 配置mysql的innodb内存占用，根据上边结果中剩余内存（取80%）增加 innodb_buffer_pool_size的值

# 配置mysql的其它内存使用和缓存使用情况，不要加的太大，主要是 sort_buffer_size, join_buffer_size, key_cache_size。

配置依据是：总内存 - OS系统预留 - max_connections * (sort_buffer_size + join_buffer_size + read_buffer_size + read_rnd_buffer_size + thread_statck ) - key_cache_size 0

2 优化调整（属于优化性能方面）

主要是以下几方面：

连接等待队列数 back_log

客户端请求线程缓存数 thread_cache_size

表缓冲的数量 table_open_cache

临时表的内存大小，用于group by的优化 tmp_table_size

innodb日志缓冲大小 innodb_log_buffer_size

innodb能打开表的数量大小（库里的表特别多时增加此项值） innodb_open_files