前言：這是最近剛發生在公司的一次應用系統的mysql調優過程，事情的過程是這樣的：公司的乙個銷售系統，用的是mysql資料庫，在元旦的前夕突然就宕機了。差不多導致業務系統4個小時左右使用有問題；
因為這個系統乙方公司尚未完全交付，所以資料庫的運維的工作，作為甲方也還未交接到我的手上，這個事情也是元旦過後上班才知道的；
其實對於這種問題我是可以不用管的，相信很多人也會選擇當作不知道。但是我還是想把問題找出來並解決掉，這個出於以下兩個原因：
以下是整個問題解決的過程：
解決過程第一步：了解系統的情況，知己知彼，百戰不殆
1、檢查作業系統的配置：cpu、記憶體、還有儲存空間（需要了解資料是放在本地硬碟還是在儲存上面，如果是本地硬碟的話，需要了解做raid幾）
2、諮詢整個系統的架構：這套系統採用了主從結構，並實現了讀寫分離（這種讀寫分離不是完全的，很多及時性要求非常高的業務讀還是在主庫上面進行）
3、檢查資料庫的引數配置：資料庫的版本、表的儲存引擎、表空間的管理、資料庫記憶體的配置等；
4、和業務諮詢該系統的使用業務型別（oltp或olap，其實很多oltp的系統偶爾也做著olap的工作）
5、了解資料庫的表資料量；（幾千行的資料跟幾百萬行的資料是完全不一樣的概念）
6、了解系統發生問題之前是否有相應的變更；
7、檢查資料庫的報錯日誌；
第二步：經過了解以上的內容之後，開啟資料庫的慢查詢日誌和沒有使用索引的語句；（把執行超過10秒的語句記錄下來）
這裡的操作步驟，在前面的文件中已經寫了，麻煩自己查詢一下；
第三步：開啟慢查詢乙個多星期之後發現了乙個很明顯的問題，這裡直接上圖
1count: 10063 time=16.94s (170462s)
update spkcb a
set
gg1_id=(select id from com_base_guige1 gg1 where gg1.ggdm = a.gg1dm limit n ),
gg2_id=(select id from com_base_guige2 gg2 where gg2.ggdm = a.gg2dm limit n ),
sp_id = (select id from com_base_shangpin sp where sp.spdm = a.spdm),
zd_id = (select id from com_base_kehu kh where kh.khdm = a.drp_ckdm)
where mid= 's'
以上只是慢查詢中的乙個最最典型的例子：有乙個過程在這差不多10天的時間裡，執行了10063次，每次執行了16.94秒，每天平均雲習慣1000次，經了解這是乙個更新庫存的語句。
這個表spkcb有30萬的資料；
再次查詢mid具有很強的選擇性；
看到這裡簡直被打敗了，這麼一條語句，居然沒有加索引。。。。。。。。。。。。。
第四步：列優化方案（時間跨度，是為了保證取樣的典型性）
1、在乙個月之內監控資料庫所有超過10秒的慢查詢日誌；
2、在第二個月開始監控資料庫所有超過5秒的慢查詢日誌；
3、在第三個月開始監控資料庫所有超過3秒的慢查詢日誌；
4、在這期間業務對於一些數量大、且實時性要求不高的表建議通過類似物化檢視的方式進行；
插曲：整個過程還讓乙方提供了解決方案：分庫分表、把一些應用搭建在阿里雲上面……………………………………………….等等一些很炫的技術方案；（接著忽悠
）從整個文件的記錄下來，我一直在思考乙個問題：為什麼乙個簡單的索引問題，乙方公司不能發現？
思考之下，得出自己的答案：
1、乙方公司沒有乙個專業的dba；
2、開發人員在設計應用的時候，工作往往停留在應用的層面，比如編寫sql語句、儲存過程之類，他們往往會忽略了這個時候索引的存在，或者認為這是dba的工作；
3、dba一般不了解業務的情況，不會在系統正常執行時新增索引，一般都是業務反饋有問題或者系統宕掉的情況下，經過監控後才增加索引的；
4、很多人員不管是乙方還是甲方技術都還是半桶水的時候，就大談資料庫架構、應用架構，其實如果真正去觀察其實很多資料庫的標準方案如果研究透了，已經足夠滿足公司的日常運營了，這些所謂架構很大一部分是在忽悠老闆的；
mysql調優經驗
訪問量越來越大，mysql自然成為瓶頸，因此最近我一直在研究 mysql 的優化，第一步自然想到的是 mysql 系統引數的優化，作為乙個訪問量很大的 日20萬人次以上 的資料庫系統，不可能指望 mysql 預設的系統引數能夠讓 mysql執行得非常順暢。通過在網路上查詢資料和自己的嘗試，我認為以下...
一次oracle調優經歷
修改oracle archive mode需要注意的地方 當時沒有記錄下具體的東西。現在寫一下 我的測試機經常死。win2k oracle 92 1 檢視alert sid.log 日誌。沒發現問題。2 為資料庫做statspace，峰值大約在早10點和下午3點左右。做了兩個statspace。看，...
記一次oracle sql調優過程
這裡兩天都在對一條sql進行調優。該sql並不複雜,類似於 select from some view union all select from some table where datetime d1 and datetime d2 and 底層使用ibatis2.1.6 oracle 10g。...