首页 > 所有文章 > 行业 >文章详情

php 获取 访问者 ip(php获取客户端ip服务端ip)

时间:2023-10-28 20:27:38 浏览量:58

大家都知道,slow query系统做的好不好,直接决定了解决slow query的效率问题

一个数据库管理平台,拥有一个好的slow query系统,基本上就拥有了解锁性能问题的钥匙

但是今天主要分享的并不是平台,而是在平台中看到的奇葩指数五颗星的slow issue

好了,关子卖完了,直接进入正题

一堆如下慢查询

从我们的监控图上可以看到,每天不定时间段的slow query 总数在攀升,但是却看不到任何query 语句

这是我接触到的slow query优化案例中从来没有过的情况,比较好奇,也比较兴奋,至此决心要好好看看这个问题

要解决这个问题,首先想到的是,如何复现这个问题,如何模拟复现这个症状

结论是: MySQL client 模拟出来的prepare 并不是我们期待的,并没有得到我们想要的 administrator command: Prepare

结论是:跟MySQL客户端一样,同样是看不到administrator command: Prepare

php模拟得到的slow 结果

结论: 通过php代码,我们成功模拟出了想要的结果

那顺藤摸瓜,抓取下这段时间有相同session id的整个sql执行过程

结论:我们发现,prepare时间的确很长,但是sql语句却执行的很快,这就很尴尬了

本来是想通过抓包,看看是否能够验证我们的猜想: prepare的语句非常大,或者条件非常复杂,从而导致prepare在服务器端很慢

结果发现query语句也都非常简单

那么既然如此,我们就找了业务方,将对应业务的prepare方法一起看看

结果发现,业务使用的是php-pdo的方式,所以我们就又有了如下发现

1. 本地prepare $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,true);

不会发送给MySQL Server

2. 服务器端prepare $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,false);

发送给MySQL Server

strace -s200 -f php mysql1.php 跟踪

大家可以看到这个模式下,prepare的时候,是将query 占位符 发送给服务端的

strace -s200 -f php mysql1.php 跟踪

大家可以看到这个模式下,prepare的时候,是不会将query发送给服务端的,只有execute的时候才会发送

跟业务方确认后,他们使用的是后者,也就是修改了默认值,他们原本是想提升数据库的性能,因为预处理后只需要传参数就好了

但是对于我们的业务场景并不适合,我们的场景是频繁打开关闭连接,也就是预处理基本就用不到

另外文档上面也明确指出prepared statements 性能会不好

如何验证业务方是否将prepare修改为local了呢?

通过观察,发现这个值没有变化,说明调整已经生效

作者:兰春