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 faia_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
1. 官方網址: https://dev.mysql.com/doc/apis-php/en/apis-php-mysqli-stmt.prepare.html <?php $link = mysqli_connect("xx", "dba", "xx", "xx_db"); /* check connection */ if (mysqli_connect_errno()) { printf("Connect failed: %s\n", mysqli_connect_error()); exit(); } $city = '1'; /* create a prepared statement */ $stmt = mysqli_stmt_init($link); if (mysqli_stmt_prepare($stmt, 'select * from xx_operation_log where id in (1,2,3)'){ /* bind parameters for markers */ /* mysqli_stmt_bind_param($stmt, "s", $city); /* execute query */ mysqli_stmt_execute($stmt); /* bind result variables */ mysqli_stmt_bind_result($stmt, $district); /* fetch value */ mysqli_stmt_fetch($stmt); printf("%s is in district %s\n", $city, $district); /* close statement */ mysqli_stmt_close($stmt); } /* close connection */ mysqli_close($link); ?>
- 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.401453Lock_time: 0.000000 Rows_sent: 0Rows_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.001650Lock_time: 0.000102 Rows_sent: 0Rows_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`=1where `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.000029Lock_time: 0.000000 Rows_sent: 0Rows_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模式
1.本地prepare$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,true); 不會發送給MySQL Server 2. 伺服器端prepare$dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,false); 傳送給MySQL Server
驗證兩種prepare模式
- 服務端prepare模式( ATTR_EMULATE_PREPARES = false)
<?php $dbms='mysql';//資料庫型別 $host='xxx'; //資料庫主機名 $dbName='test';//使用的資料庫 $user='xx';//資料庫連線使用者名稱 $pass='123456';//對應的密碼 $dsn="$dbms:host=$host;dbname=$dbName"; try { $pdo = new PDO($dsn, $user, $pass); //初始化一個PDO物件 $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES,false); echo "----- prepare begin -----\n"; $stmt = $pdo->prepare("select * from test.chanpin where id = ?"); echo "----- prepare after -----\n"; $stmt->execute([333333]); echo "----- execute after -----\n"; $rs = $stmt->fetchAll(); } catch (PDOException $e) { die ("Error!: " . $e->getMessage() . "<br/>"); }
strace -s200 -f php mysql1.php 跟蹤
大家可以看到這個模式下,prepare的時候,是將query+佔位符 傳送給服務端的
- 本地prepare模式 (ATTR_EMULATE_PREPARES = true )
<?php $dbms='mysql';//資料庫型別 $host='xx'; //資料庫主機名 $dbName='test';//使用的資料庫 $user='xx';//資料庫連線使用者名稱 $pass='123456';//對應的密碼 $dsn="$dbms:host=$host;dbname=$dbName"; try { $pdo = new PDO($dsn, $user, $pass); //初始化一個PDO物件 $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES,true); echo "----- prepare begin -----\n"; $stmt = $pdo->prepare("select * from test.chanpin where id = ?"); echo "----- prepare after -----\n"; $stmt->execute([333333]); echo "----- execute after -----\n"; $rs = $stmt->fetchAll(); } catch (PDOException $e) { die ("Error!: " . $e->getMessage() . "<br/>"); }
strace -s200 -f php mysql1.php 跟蹤
大家可以看到這個模式下,prepare的時候,是不會將query傳送給服務端的,只有execute的時候才會傳送
跟業務方確認後,他們使用的是後者,也就是修改了預設值,他們原本是想提升資料庫的效能,因為預處理後只需要傳引數就好了
但是對於我們的業務場景並不適合,我們的場景是頻繁開啟關閉連線,也就是預處理基本就用不到
另外文件上面也明確指出prepared statements 效能會不好
調整和驗證
如何驗證業務方是否將prepare修改為local了呢?
dba:(none)> show global status like 'Com_stmt_prepare'; +------------------+-----------+ | Variable_name | Value | +------------------+-----------+ | Com_stmt_prepare | 716836596 | +------------------+-----------+ 1 row in set (0.00 sec)
通過觀察,發現這個值沒有變化,說明調整已經生效
總結
- prepare的優點
1.防止SQL注入 2.特定場景下提升效能 什麼是特定場景: 就是先去服務端用佔位符佔位,後面可以直接傳送請求來填空(引數值) 這樣理論上來說, 你填空的次數非常多,效能才能發揮出來
- prepare的缺點
1. 在伺服器端的prepare畢竟有消耗,當併發量大,頻繁prepare的時候,就會有效能問題 2. 服務端的prepare模式還會帶來的另外一個問題就是,排錯和slow 優化有困難,因為大部分情況下是看不到真實query的 3. 儘量設定php-pdo為$pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES,true) ,在本地prepare,不要給伺服器造成額外壓力
- 建議
1. 預設情況下,應該使用php-pdo的預設配置,採用本地prepare的方式,這樣可以做到防SQL注入的效果,效能差不到哪裡去 2. 除非真的是有上述說的特定場景,可以考慮配置成伺服器prepare模式,前提是要做好測試