資料庫慢，如何排查？以下是總結的一些思路。

資料庫應用，常見兩種型別：CPU密集型和I/O密集型。因此，我們在排查資料庫問題時，通常是從這兩方面入手的。

CPU密集型的資料庫，效能問題有以下幾種：
1.複雜的查詢語句、儲存過程、觸發器、自定義函式等；

2.鎖競爭問題；

3.併發量大。

解決問題的思路：

1.通過慢查詢日誌，找出相關語句，優化查詢語句調整索引策略。還可以將複雜儲存過程、觸發器、自定義函式交由應用程式碼實現；

2.根據infomation_schema中的innodb_trx、innodb_locks、innodb_lock_watis三種表，找出鎖的事務與開發協調。如果場景允許，可以考慮把事務隔離級別降到讀提交。

3.做讀寫分離、水平拆分。或者增加快取層，讓高併發的讀寫壓力由快取層消化；

4.調整mysql跟cpu相關引數，這裡不一一羅列。

I/O密集型的資料庫，效能問題有以下幾種：
1.投影了所有欄位、全表掃描、表結構設計、索引設計問題等；

2.記憶體緩衝區設定過小，造成了過多的磁碟I/O；

3.網路頻寬較小（常見於分散式系統中）。

解決問題的思路：

1.通過慢查詢日誌，找出執行時間久，而且結果集大的語句。減少投影的欄位，只選擇必要的欄位做投影，優化表結構與索引設計；

2.調整記憶體緩衝區、日誌重新整理、重新整理方法等等引數的設定，這裡不一一羅列；

3.提升網路頻寬，調整核心引數。

如果上述措施還不能解決問題或者效果不明顯，可以考慮擴容。擴容分為：縱向擴充套件和橫向擴充套件。

橫向擴充套件：一般用於解決高併發量問題。比如做簡單的讀寫分離、使用mycat將資料量做分片等，儘量將單機壓力分擔出去。

這裡提到了解決高併發量的問題，其實還可以用非同步的方式，將壓力前移到快取層，降低寫入壓力；同時，快取一些熱點資料，也能大大減輕讀壓力。