MySQL运维拭魅战之PHP会见MySQL，你行使对了吗

各人都知道，slow query体系做的好欠好，直接抉择了办理slow query的服从题目。

一个数据库打点平台，拥有一个好的slow query体系，根基上就拥有相识锁机能题目的钥匙。

可是本日首要分享的并不是平台，而是在平台中看到的奇葩指数五颗星的slow issue。

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

一、症状 

一堆如下慢查询  

# User@Host: cra[cra] @ [xx] Id: 3352884621  
# Query_time: 0.183673 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0  
use xx_db;  
SET timestamp=1549900927;  
# administrator command: Prepare;  
# Time: 2019-02-12T00:02:07.516803+08:00  
# User@Host: cra[cra] @ [xx] Id: 3351119968  
# Query_time: 0.294081 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0  
SET timestamp=1549900927;  
# administrator command: Prepare; 

从我们的监控图上可以看到，天天不按时刻段的slow query 总数在攀升，可是却看不到任何query 语句。

这是我打仗到的slow query优化案例中从来没有过的环境，较量好奇，也较量欢快，至此刻意要好悦目看这个题目。

二、排查

要办理这个题目，起首想到的是，怎样复现这个题目，怎样模仿复现这个症状。

•  MySQL客户端 模仿prepare 

* 模仿  
root:xx> prepare stmt1 from 'select * from xx_operation_log where id = ?';  
Query OK, 0 rows affected (0.00 sec)  
Statement prepared  
* 功效  
# Time: 2019-02-14T14:14:50.937462+08:00  
# User@Host: root[root] @ localhost [] Id: 369  
# Query_time: 0.000105 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0  
SET timestamp=1550124890;  
prepare stmt1 from 'select * from xx_operation_log where id = ?'; 

结论是： MySQL client 模仿出来的prepare 并不是我们等候的，并没有获得我们想要的 administrator command: Prepare。

•  perl 模仿prepare 

#!/usr/bin/perl  
use DBI;  
my $dsn = "dbi:mysql:database=${db_name};hostname=${db_host};port=${db_port}";#数据源  
#获取数据库句柄  
my $dbh = DBI->connect("DBI:mysql:database=xx;host=xx", "xx", "xx", {'RaiseError' => 1});  
my $sql = qq{select * from xx_operation_log where id in (?)};  
my $sth = $dbh->prepare($sql);  
$sth->bind_param (1, '100');  
sleep 3;  
$sth->execute(); 

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

•  php 模仿prepare

php模仿获得的slow 功效：

[root@xx 20190211]# cat xx-slow.log | grep 'administrator command: Prepare' -B4 | grep 'User@Host' | grep 'xx_rx' | wc -l  
7891  
[root@xx 20190211]# cat xx-slow.log | grep 'administrator command: Prepare' -B4 | grep 'User@Host' | wc -l  
7908 

结论： 通过php代码，我们乐成模仿出了想要的功效。

那顺藤摸瓜，抓取下这段时刻有沟通session id的整个sql执行进程。

MySQL开启slow=0的抓包模式

可以定位到统一个session id（3415357118） 的 prepare + execute + close stmt  
# User@Host: xx_rx[xx_rx] @ [xx.xxx.xxx.132] Id: 3415357118  
# Query_time: 0.401453 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 0  
use xx_db;  
SET timestamp=1550017125;  
# administrator command: Prepare;  
# Time: 2019-02-13T08:18:45.624671+08:00  
--  
# User@Host: xx_rx[xx_rx] @ [xx.xxx.xxx.132] Id: 3415357118  
# Query_time: 0.001650 Lock_time: 0.000102 Rows_sent: 0 Rows_examined: 1  
use xx_db;  
SET timestamp=1550017125;  
update `xx` set `updated_at` = '2019-02-13 08:18:45', `has_sales_office_phone` = 1, `has_presale_permit` = 1 where `id` = 28886;  
# Time: 2019-02-13T08:18:45.626138+08:00  
--  
# User@Host: xx_rx[xx_rx] @ [xx.xxx.xxx.132] Id: 3415357118  
# Query_time: 0.000029 Lock_time: 0.000000 Rows_sent: 0 Rows_examined: 1  
use xx_db;  
SET timestamp=1550017125;  
# administrator command: Close stmt;  
# Time: 2019-02-13T08:18:45.626430+08:00 

结论：我们发明，prepare时刻简直很长，可是sql语句却执行的很快，这就很忧伤了。

原来是想通过抓包，看看是否可以或许验证我们的意料： prepare的语句很是大，可能前提很是伟大，从而导致prepare在处事器端很慢。

功效发明query语句也都很是简朴。

那么既然云云，我们就找了营业方，将对应营业的prepare要领一路看看。

功效发明，营业行使的是php-pdo的方法，以是我们就又有了如下发明：

php-pdo 两种prepare模式

•  http://php.net/manual/zh/pdo.prepare.php

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

不会发送给MySQL Server

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

发送给MySQL Server

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!