帮我看下这些日志吧好心人

补：
套 cdn 建议是国内 cdn ，源站国外，否则很容易会被 GFW 阻断连接

@mengzhuo 主要是我心理上过意不去…

如果觉得是 mysql 问题就开启慢查询日志然后导出来瞅瞅
或者在非生产环境跑个并发测试看看
冷静下来,问题终归会解决的

@mengzhuo 噗,这样真的大丈夫?

@quericy 嗯嗯已经开启慢查询，就等着死机了。

楼主加油，一起学习~~

网址多少

@quericy 实习的时候捅的篓子，
delete 忘了加 where limit
删了近十年的数据，当时就懵 b 了，然后被赶到的经理痛骂一顿
dba 知道我是实习生，就说了句：下次别忘了加 limit 。
就跑去恢复备份了。

@mengzhuo

有故事的人

给大家说说昨天的排查过程吧，因为干扰源存在，问题未最终解决。

开头时候服务器环境的不熟悉浪费大量时间。。
找配置文件，塞个 htop ，塞个 iftop ，因为 CentOS 仅仅在内网用过（无外网访问权限），傻乎乎的就去找包了，结果 CentOS 7 ，半天没找着，最后 yum 发现都能用

翻查 mysql 的实际调用配置文件位置浪费了不少时间。。

======================================

刚开始看在本页页头的日志文件，感觉应该是 PHP-FPM/MySQL 阻塞 /挂掉，所以从这个地方入手。
先把看起来有问题的性能参数都给改了， MySQL 的查询缓存开大点。（ 4G 内存，大着呢）
压测发现 PHP-FPM 稳定承受所有请求， CPU 占用率未有明显异常，无错误报告。
但同时 MySQL CPU 占用跑满，遂排查。。

首先把 MySQL 的慢查询开了，超时 1 秒，记录日志
压测 50 线程，力求打满。。。然并卵，机器的带宽就 4M ，折算下来理论 512KB/S
（事实上跑了 3M 的带宽，结果还是个位数的每秒响应）
MySQL 占用继续跑满，但是慢查询没任何异常（未有任何一条数据输出）。
多次测试情况一致。。。页面几乎无反应（ 20 秒+）

压测过程中 show processlist; 命令查看当前 SQL 字串，存在大量查询正在 Creating sort index.
"SELECT t.*, tt.*, tr.object_id FROM wp_terms AS t INNER JOIN wp_term_taxonomy AS tt ON tt.term_id = t.term_id ........."
（说好的缓存呢？）

翻查数据库，数据是分类类目、 tag 之类的东西
遂翻查代码，首页大量调用 get_post_meta / get_the_category, 对 WP 不熟，但至少反查上去这两个嫌疑最大，结合上面那条 SQL 提到的那些表的数据，看上去，似乎，首页的大部分文章，都调用了一次。。。

传说中的 97 次 SQL ？

这个算是其一，另外在 show processlist;过程中存在大量的 ALERT TABLE 请求。。。
逻辑告诉我，大概是楼主在导数据吧。。。

。。。。。
。。。。
。。。
。。
。


但是在多次压测的时候我还能看到这东西。。。
复制一行，问楼主：
"ALTER TABLE vp_msg CHANGE COLUMN Status Status TINYINT NOT NULL"
"长这样的 mysql 语句你有印象么"

"我知道，这是我自己创建的数据表"
"这句有问题吗"

"...为啥我每次访问首页都能看到这行东西 "

..............

屏蔽过后，压测稳定了，至少能稳稳当当的在我可接受的时间内跑完全程，并发 10 （但依旧占用 100%）
在那堆查询问题解决之前，无法进入下一步排查，算是干扰源。

以上就是昨日下午排查的结果。

楼上厉害啊。
学习下测试流程。

@mhycy
wordpress 自身就有优化语句和索引了
难道楼主是自己写 SQL 的么……难为他和你了