周末外出和朋友一起钓鱼去了,晚上回来准备在自己的米扑博客https://blog.mimvp.com)写一篇钓鱼游记,打开电脑结果发现博客网站打不开了,提示”建立数据库连接时出错

wordpress_db_fix_05

好吧,问题已经很明了了,白天我去池塘钓别人的鱼,别人却在网上掉我的鱼,把我的博客网站整塌了...

废话多说无益,开工吧

 

问题分析

首先,备份数据库

备份博客数据库时,提示错误 "Table './db_name/table_name' is marked as crashed and last (automatic?) repair failed" when using LOCK TABLES

wordpress_db_fix_03

提示信息已经很明了了,是锁定数据库表后,自动修复数据库失败,导致无法从数据库查询出数据。

 

接着,网页修复数据库

WordPress 带有网页自动修复数据库的功能,在浏览器输入自己博客管理员域名,例如: 米扑博客

https://blog.mimvp.com/wp-admin/

wordpress_db_fix_01

按照引导提示,点击“修复数据库”,继续

wordpress_db_fix_02

按照引导提示,添加如下一行宏定义,到自己博客根目录下的 wp-config.php 文件的最底部

define('WP_ALLOW_REPAIR', true);

保存,刷新一下页面,继续出现下图

wordpress_db_fix_04

按照引导提示,点击“修复并优化数据库”,结果会提示首先备份数据库一样的错误,再次确认是数据库表被锁定导致的问题。

修复并优化数据库后,可能还会有部分表的错误无法修复,如下图提示:

wordpress_db_fix_101

 

问题解决

问题1) wp_usermeta: 1 client is using or hasn't closed the table properly

               wp_postmeta: 1 client is using or hasn't closed the table properly

原因分析

myisam表会经常出现这种现象

问题解决

repair table 表名       (先登录MySQL,然后use dbname,最后执行 repair table table_name
或者 alter table 表名 engine innodb
或者 增加key_buffer_size

修复效果如下图:

wordpress_db_fix_100

 

问题2) wp_options: Table is marked as crashed and last repair failed

"Table './db_name/table_name' is marked as crashed and last (automatic?) repair failed" when using LOCK TABLES

这个问题的原因,大多是myisam表数据太多,在某个时刻存放数据的这个MyISAM表数据急速长大,比如一些log表,当把硬盘写满了时还在继续写入,然后这个表就会lock掉;或者是mysiam的存储表的文件tbl_name.MYI 损坏了

解决

找到mysql的数据库存放的文件夹,一般默认在 /var/lib/mysql/ 目录下

或者去mysql的配置文件 my.cnf (linux)  或 my.ini(windows) 里面找 datadir 路径

例如: vim /etc/my.cnf

wordpress_db_fix_06

找到对应的数据库文件夹进去后,在该数据库文件夹下执行命令:

myisamchk -r <table_name>

其中,<table_name> 是想要修复的表名,如 wordpress/wp_options
 
如果这样还不能解决,那么先停掉mysql,然后执行命令:

myisamchk -r -v -f <table_name>

修复效果如下图:

wordpress_db_fix_102

 

MySQL 优化 key_buffer_size 

key_buffer_size指定索引缓冲区的大小,它决定索引处理的速度,尤其是索引读的速度。通过检查状态值Key_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。

MariaDB [wordpress]> show variables like 'key_buffer_size';
+-----------------+-----------+
| Variable_name   | Value     |
+-----------------+-----------+
| key_buffer_size | 134217728 |
+-----------------+-----------+

MariaDB [wordpress]> show global status like 'key_read%';
+-------------------+--------+
| Variable_name     | Value  |
+-------------------+--------+
| Key_read_requests | 330120 |
| Key_reads         | 5604   |
+-------------------+--------+

MariaDB [wordpress]> show global status like 'key_blocks_u%';
+-------------------+--------+
| Variable_name     | Value  |
+-------------------+--------+
| Key_blocks_unused | 105262 |
| Key_blocks_used   | 2819   |
+-------------------+--------+

两者 比例值 = key_reads / key_read_requests,应该尽可能的低,至少是1:100,1:1000更好(上述状态值可以使用SHOW STATUS LIKE ‘key_read%’获得)。

key_buffer_size只对MyISAM表起作用

即使你不使用MyISAM表,但是内部的临时磁盘表是MyISAM表,也要使用该值。

可以使用检查状态值created_tmp_disk_tables得知详情。

对于1G内存的机器,如果不使用MyISAM表,推荐值是16M(8-64M)

提升性能的建议:

1.如果opened_tables太大,应该把my.cnf中的table_cache变大

2.如果Key_reads太大,则应该把my.cnf中key_buffer_size变大.可以用Key_reads/Key_read_requests计算出cache失败率

3.如果Handler_read_rnd太大,则你写的SQL语句里很多查询都是要扫描整个表,而没有发挥键的作用

4.如果Threads_created太大,就要增加my.cnf中thread_cache_size的值.可以用Threads_created/Connections计算cache命中率

5.如果Created_tmp_disk_tables太大,就要增加my.cnf中tmp_table_size的值,用基于内存的临时表代替基于磁盘的  

 

总结

我的问题,通过进入MySQL数据库目录下后,执行 myisamchk -r <table_name> 就解决了

解决的米扑博客示例: https://blog.mimvp.com