MySQL機能瓶頸排查定位實例詳解。本站提示廣大學習愛好者：（MySQL機能瓶頸排查定位實例詳解）文章只能為提供參考，不一定能成為您想要的結果。以下是MySQL機能瓶頸排查定位實例詳解正文
本文實例講述了Python完成二分查找算法的辦法。分享給年夜家供年夜家參考。詳細完成辦法以下：
#!/usr/bin/env python
import sys
def search2(a,m):
low = 0
high = len(a) - 1
while(low <= high):
mid = (low + high)/2
midval = a[mid]
if midval < m:
low = mid + 1
elif midval > m:
high = mid - 1
else:
print mid
return mid
print -1
return -1
if __name__ == "__main__":
a = [int(i) for i in list(sys.argv[1])]
m = int(sys.argv[2])
search2(a,m)
運轉:
administrator@ubuntu:~/Python$ python test_search2.py 123456789 4
3
注:
1.'__'：因為python的類成員都是私有、地下的被存取public，缺乏像正統面向對象說話的公有private屬性。
因而就用__來遷就一下，模仿公有屬性。這些__屬性常常是外部應用，平日情形下不消改寫。也不消讀取。
加上2個下劃線的目標，一是和睦通俗私有屬性重名抵觸，二是不讓對象的應用者(非開辟者)隨便應用。
2.__name__ == "__main__"表現法式劇本是直接被履行的.
假如不等於表現劇本是被其他法式用import引入的.則其__name__屬性被設為模塊名
願望本文所述對年夜家的Python法式設計有所贊助。
-q 1 Linux 2.6.32-431.el6.x86_64 (yejr.imysql.com) 01/13/2016 _x86_64_ (24 CPU) 02:51:18 PM runq-sz plist-sz ldavg-1 ldavg-5 ldavg-15 blocked 02:51:19 PM 4 2305 6.41 6.98 7.12 3 02:51:20 PM 2 2301 6.41 6.98 7.12 4 02:51:21 PM 0 2300 6.41 6.98 7.12 5 02:51:22 PM 6 2301 6.41 6.98 7.12 8 02:51:23 PM 2 2290 6.41 6.98 7.12 8load average年夜意表現以後CPU中有若干義務在列隊期待，期待越多解釋負載越高，跑數據庫的辦事器上，普通load值跨越5的話，曾經算是比擬高的了。
惹起load高的緣由也能夠有多種：
某些過程/辦事消費更多CPU資本(辦事呼應更多要求或存在某些運用瓶頸)；
產生比擬嚴重的swap(可用物理內存缺乏)；
產生比擬嚴重的中止(由於SSD或收集的緣由產生中止)；
磁盤I/O比擬慢(會招致CPU一向期待磁盤I/O要求)；
這時候我們可以履行上面的敕令來斷定究竟瓶頸在哪一個子體系：
[[email protected]:~ ]# top top - 11:53:04 up 702 days, 56 min, 1 user, load average: 7.18, 6.70, 6.47 Tasks: 576 total, 1 running, 575 sleeping, 0 stopped, 0 zombie Cpu(s): 7.7%us, 3.4%sy, 0.0%ni, 77.6%id, 11.0%wa, 0.0%hi, 0.3%si, 0.0%st Mem: 49374024k total, 32018844k used, 17355180k free, 115416k buffers Swap: 16777208k total, 117612k used, 16659596k free, 5689020k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 14165 mysql 20 0 8822m 3.1g 4672 S 162.3 6.6 89839:59 mysqld 40610 mysql 20 0 25.6g 14g 8336 S 121.7 31.5 282809:08 mysqld 49023 mysql 20 0 16.9g 5.1g 4772 S 4.6 10.8 34940:09 mysqld
很顯著是後面兩個mysqld過程招致全體負載較高。
並且，從 Cpu(s) 這行的統計成果也能看的出來，%us 和 %wa 的值較高，表現以後比擬年夜的瓶頸能夠是在用戶過程消費的CPU和磁盤I/O期待上。
我們先剖析下磁盤I/O的情形。
履行 sar -d 確認磁盤I/O能否真的較年夜：
[[email protected]:~ ]# sar -d 1 Linux 2.6.32-431.el6.x86_64 (yejr.imysql.com) 01/13/2016 _x86_64_ (24 CPU) 11:54:32 AM dev8-0 5338.00 162784.00 1394.00 30.76 5.24 0.98 0.19 100.00 11:54:33 AM dev8-0 5134.00 148032.00 32365.00 35.14 6.93 1.34 0.19 100.10 11:54:34 AM dev8-0 5233.00 161376.00 996.00 31.03 9.77 1.88 0.19 100.00 11:54:35 AM dev8-0 4566.00 139232.00 1166.00 30.75 5.37 1.18 0.22 100.00 11:54:36 AM dev8-0 4665.00 145920.00 630.00 31.41 5.94 1.27 0.21 100.00 11:54:37 AM dev8-0 4994.00 156544.00 546.00 31.46 7.07 1.42 0.20 100.00
再應用 iotop 確認究竟哪些過程消費的磁盤I/O資本最多：
[[email protected]:~ ]# iotop Total DISK READ: 60.38 M/s | Total DISK WRITE: 640.34 K/s TID PRIO USER DISK READ DISK WRITE SWAPIN IO> COMMAND 16397 be/4 mysql 8.92 M/s 0.00 B/s 0.00 % 94.77 % mysqld --basedir=/usr/local/m~og_3320/mysql.sock --port=3320 7295 be/4 mysql 10.98 M/s 0.00 B/s 0.00 % 93.59 % mysqld --basedir=/usr/local/m~og_3320/mysql.sock --port=3320 14295 be/4 mysql 10.50 M/s 0.00 B/s 0.00 % 93.57 % mysqld --basedir=/usr/local/m~og_3320/mysql.sock --port=3320 14288 be/4 mysql 14.30 M/s 0.00 B/s 0.00 % 91.86 % mysqld --basedir=/usr/local/m~og_3320/mysql.sock --port=3320 14292 be/4 mysql 14.37 M/s 0.00 B/s 0.00 % 91.23 % mysqld --basedir=/usr/local/m~og_3320/mysql.sock --port=3320
可以看到，端標語是3320的實例消費的磁盤I/O資本比擬多，那就看看這個實例裡都有甚麼查詢在跑吧。
2. MySQL層面檢討確認
起首看下以後都有哪些查詢在運轉：
[[email protected](db)]> mysqladmin pr|grep -v Sleep +----+----+----------+----+-------+-----+--------------+-----------------------------------------------------------------------------------------------+ | Id |User| Host | db |Command|Time | State | Info | +----+----+----------+----+-------+-----+--------------+-----------------------------------------------------------------------------------------------+ | 25 | x | 10.x:8519 | db | Query | 68 | Sending data | select max(Fvideoid) from (select Fvideoid from t where Fvideoid>404612 order by Fvideoid) t1 | | 26 | x | 10.x:8520 | db | Query | 65 | Sending data | select max(Fvideoid) from (select Fvideoid from t where Fvideoid>484915 order by Fvideoid) t1 | | 28 | x | 10.x:8522 | db | Query | 130 | Sending data | select max(Fvideoid) from (select Fvideoid from t where Fvideoid>404641 order by Fvideoid) t1 | | 27 | x | 10.x:8521 | db | Query | 167 | Sending data | select max(Fvideoid) from (select Fvideoid from t where Fvideoid>324157 order by Fvideoid) t1 | | 36 | x | 10.x:8727 | db | Query | 174 | Sending data | select max(Fvideoid) from (select Fvideoid from t where Fvideoid>324346 order by Fvideoid) t1 | +----+----+----------+----+-------+-----+--------------+-----------------------------------------------------------------------------------------------+
可以看到有很多慢查詢還未完成，從slow query log中也能發明，這類SQL產生的頻率很高。
這是一個異常低效的SQL寫法，招致須要對全部主鍵停止掃描，但現實上只須要獲得一個最年夜值罷了，從slow query log中可看到：
Rows_sent: 1 Rows_examined: 5502460
每次都要掃描500多萬行數據，卻只為讀取一個最年夜值，效力異常低。
經由剖析，這個SQL稍做簡略改革便可在個位數毫秒級內完成，本來則是須要150-180秒能力完成，晉升了N次方。
改革的辦法是：對查詢成果做一次倒序排序，獲得第一筆記錄便可。而本來的做法是對成果正序排序，取最初一筆記錄，汗啊。。。
寫在最初，小結
在這個例子中，發生瓶頸的緣由比擬好定位，SQL優化也不難，現實線上情況中，平日有以下幾種罕見的緣由招致負載較高：
一次要求讀寫的數據量太年夜，招致磁盤I/O讀寫值較年夜，例如一個SQL裡要讀取或更新幾萬行數據乃至更多，這類最好是想方法削減一次讀寫的數據量；
SQL查詢中沒有恰當的索引可以用來完成前提過濾、排序(ORDER BY)、分組(GROUP BY)、數據聚合(MIN/MAX/COUNT/AVG等)，添加索引或許停止SQL改寫吧；
剎時突發有年夜量要求，這類普通只需能扛過峰值就好，保險起見照樣要恰當進步辦事器的設置裝備擺設，萬一峰值抗不外去便可能產生雪崩效應；
由於某些准時義務惹起的負載降低，好比做數據統計剖析和備份，這類對CPU、內存、磁盤I/O消費都很年夜，最好放在自力的slave辦事器上履行；
辦事器本身的節能戰略發明負載較低時會讓CPU降頻，當發明負載降低時再主動升頻，但平日不是那末實時，成果招致CPU機能缺乏，抗不外突發的要求；
應用raid卡的時刻，平日裝備BBU(cache模塊的備用電池)，晚期普通采取锂電池技巧，須要按期充放電(DELL辦事器90天一次，IBM是30天)，我們可以經由過程監控鄙人一次充放電的時光前在營業低谷時提早對其停止放電，不外新一代辦事器年夜多采取電容式電池，也就不存在這個成績了。
文件體系采取ext4乃至ext3，而不是xfs，在高I/O壓力時，極可能招致%util曾經跑到100%了，但iops卻沒法再晉升，換成xfs普通可取得年夜幅晉升；
內核的io scheduler戰略采取cfq而非deadline或noop，可以在線直接調劑，也可取得年夜幅晉升。
願望本文所述對年夜家MySQL數據庫計有所贊助。
