01 找钥匙的傻方法——人力穷举和排除
之所以用找钥匙为例，就是说有点儿繁杂，不知道网站的问题到底出在哪。好比一大串钥匙，找到了锁就开了，没找到的话，就一直停在那。
网站症状：
1月10号前后更换网站SSL证书（续费也是每年一换）后，发现网站后台发布文章似乎有些卡顿，当时没在意，还有其他事要做。年后发现网站打开访问时，加载特别慢。不是一般的慢，是前台卡后台都特别卡，访问网站首页或任一页面，至少有45秒以上的白屏，甚至更长的响应时间。
查看宝塔面板后台，负载瞬间达到100%。
但是同一台主机下的另一个网站，打开速度仍是正常，没有明显的变慢的迹象。
所以就得找问题所在。
1.难道是主题有问题？
于是升级主题至最新版，还是卡。
看主题，支持版本首选wordpress5.9及以上，于是升级5.9，卡，又看到文章说，wordpress6.0实现 0 SQL ，于是又将版本升级至最新版6.1，然并卵，还是卡。
2.难道是域名解析DNS的问题？
因为之前在同一域名注册商下的网站，刚好出现域名解析不正常的问题，换了个DNS就解析正常了。于是也将域名换了个DNS，然后PING，正常。
但是浏览网站，还是卡，不到一分钟的时间，浏览器是空白，网页不显示出来。
3.难道是环境不对？
例如当前环境是APACHE+PHP7.2，那换个环境试试，于是网站搬迁至APACHE+7.4环境还是一样。
4.难道是SSL证书（国外的）有问题？
于是把申请证书时做的txt解析删除掉（包托以前的），也没有用。有技术文章说，NGINX对SSL的支持更好，于是再不遗余力，搬到nginx+php7.4的环境。
还是一样。甲爸给整得没有脾气了。
这说明和环境没有关系。先放一放。
再次回到网站本身，首先屏蔽了GOOGLE字体，没用。然后开始用到GOOGLE 开发者工具，终于发现一个问题：就是加载CSS、图片等都没问题，惟独加载document耗时很长，网上一找资料，原来这个问题叫作：TTFB。
参见：什么是网站TTFB？
那就调整这个TTFB。
于是按照方法优化清理了好几个表，wp_posts、postmeta、包括wp_options在内。可参见：
的确，明显看到无用的记录少了，表的容量变小了等，“减肥瘦身”的作用倒是达到。
但是，网站加载还是卡。
于是又给网站配上了Memcached，命中比例不低啊，可是网站访问还是卡。
困惑就在这儿，到底是服务器环境，还是SSL证书或DNS解析，还是主题模板哪根筋不对呢？
和PHP-FPM的配置有关吗？应该也是没有。
回到技术，这篇文章给了一个判断的依据。
文中说，出现这个问题，很明显数据库问题，要么SQL慢，要么锁表了。
于是查看MYSQL运行日志，发现一个错误：
难道要去解决这个Page Cleaner的刷脏问题？！
不对！问题应该是和数据库关系最大，但问题不在这个上page cleaner上。
修改调整MYSQL各项设置，影响的不只是这一个网站，还有其他wordpress+mysql的网站，为何其他网站不卡，就是你的这个网站卡。还是得缩小排查范围，回到此网站本身，和大环境无关。
还是去清理一下网站所对应的数据库试试。
去闪电博的WORDPRESS优化专栏查看文章，发现有一篇讲优化清理wp_options，的确，我的网站对应的MYSQL的wp-options表有3MB之多，也需要优化一下。
于是按其方法实践，竟然发现了问题所在。
真是：踏破铁鞋无觅处，得来全不费功夫。
02 清理wp-optins表，发现cron这个罪魁祸首
下面是具体的操作实践，请对照此文：如何清理wp_options表和自动加载的数据 来参看。
1.首先，进入PHPMYADMIN后台，然后查看一下wp-options表的大小，例如我的有3MB之多，就应该清理一下。
2.按文章，在SQL中运行查询：SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';
结果出来，见下图。
按文章所说，6个数字（字节）表示1MB以下，属正常，我这有7个数字，是其10倍，那就有问题了。
于是执行如下语句，找到TOP10。
SELECT option_name, length(option_value) AS option_value_length FROM wp_options WHERE autoload='yes' ORDER BY option_value_length DESC LIMIT 10;
结果出来。
其他我都知道是个啥，但CRON、izt_theme_options这两个是什么？而且cron占了2593196(大于6位，应该是有2MB之多......那网页打开自动加载这个选项，岂不是很无力~)
我知道，现有网站是没有用到这两个的，是过去使用的遗留。
文章不再看了，直接删除这两个。
删除后，可再次运行SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload='yes';，查看结果。可以看到，返回的字节不再超过6个数字。
然后打开网站，刷新页面，加载正常不再响应太长的白屏时间。问题终于解决。
03 后记
这个东西耗费了近一周（当然，不是全都用来弄这个）的时间进行测试找问题。
归根结底，问题在于数据库的SQL访问慢了，原因是wp-options里autoload=yes自动加载项里的cron太大，直接清除掉就回归正常。
博文有价值的地方在于：
- 问题排查，用笨拙的穷举排查方法找到问题所在，如果下次你碰上，就有前车之鉴不必再折腾；
- 用SQL来实现wp-options表清理的有效语句。
最后，这样一折腾，我想我都可以提供WORDPRESS网站速度优化及运营指导服务了。
