一、現象
tps很低，響應時間很長，資料庫伺服器cpu很高（接近100%），應用伺服器負載比較低
二、開啟慢查詢配置
1、在mysql配置檔案/etc/my.cnf中增加：
slow_query_log=1
long_query_time=0.1
slow_query_log 這是乙個布林型變數，預設為真。沒有這變數，資料庫不會列印慢查詢的日誌。
long_query_time=0.1：列印查詢時間超過100ms的日誌
備註：配置完成後，重新啟動mysql服務才能生效，預設情況下，慢查詢日誌生成在/var/lib/mysql 目錄下，日誌名稱為_slow-query.log
2、檢視慢查詢是否開啟：
2.1 開啟資料庫命令列介面：
2.2 執行命令show variables like '%slow_query_log%'
3、慢查詢日誌分析
在/usr/bin 目錄下，使用 mysql 自帶命令 mysqldumpslow ，
mysqldumpslow –s at -t 10 mycentos-slow.log，顯示耗時最長的10條sql語句的執行資訊
-s：排序的意思
at：**erage time，平均響應時間
-t：top，即為返回前面多少條資料
以count: 3979 time=1.14s (4551s) lock=0.00s (2s) rows=1.0 (3979)為例：
count:3979 該 sql 總共執行 3979 次
time = 1.14 (4551s) 平均每次執行該 sql 耗時 1.14 秒，總共耗時 3979（次）*1.14（秒）=4551秒
lock=0.00s(2s) lock 時間 2秒
rows =1.0(3979) 每次執行 sql 影響資料庫表中的 1 行記錄，總共影響 1（行）*3979（次）=3979 行記錄
4、執行計畫：
4.1 把上一步驟獲取的sql語句複製到n**icat查詢介面
4.2 在sql語句前加上explain，可以分析這條sql語句的執**況
4.3 type列可能的值：
const：表中只有乙個匹配行，用到primary key或unique key
eq_ref：唯一性索引掃瞄，key的所有部分被連線聯接查詢使用，且key是unique或primary key
ref：非唯一性索引掃瞄，或只使用了聯合索引的最左字首
range：索引範圍掃瞄，在索引列上進行給定範圍內的檢索，如between，in（1,100）
index：遍歷索引...
all：全表掃瞄
從上到下，效能越來越差
三、增加索引：
1、設計表-->索引
2、索引名：idx_欄位名
3、索引型別，一般選擇unique或normal，如果查詢結果只有乙個，選unique；如果查詢結果有多個，選normal
4、索引方法：一般選btree
5、一般表中的索引不能超過4個，因為索引會占用磁碟空間，而且索引會引起更新資料的效能變差
四、聯合索引
聯合索引：乙個索引同時作用於多個字段
聯合索引最左原則：
聯合索引檢索資料時，會從最左邊開始匹配（忽略sql欄位順序），如果匹配不到，就不使用索引
如：user表有聯合索引 my_index(a欄位，b欄位，c欄位)
五、分析
資料庫伺服器cpu高，一般都是因為sql執行效率低導致的，可能有三方面原因：
1、資料庫表缺少必要的索引；
2、索引不生效
3、sql不夠優化
資料庫索引效能提公升
乙個索引是儲存的表中乙個特定列的值資料結構 最常見的是b tree 索引是在表的列上建立。所以，要記住的關鍵點是索引包含乙個表中列的值，並且這些值儲存在乙個資料結構中。請記住記住這一點 索引是一種資料結構 b tree 是最常用的用於索引的資料結構。因為它們是時間複雜度低，查詢 刪除 插入操作都可以...
資料庫索引失效問題
通俗的說，索引的作用就像目錄一樣，是與表或檢視關聯的磁碟上結構，可以加快從表或檢視中檢索行的速度。索引中包含由表或檢視中的一列或多列生成的鍵。這些鍵儲存在乙個結構 btree 中，使sql可以快速有效地查詢與鍵值關聯的行。這是因為，建立索引可以大大提高系統的效能。通過建立唯一性索引，可以保證給資料庫...
資料庫索引相關問題
問題1.資料庫為什麼要設計索引？圖書館存了1000w本圖書，要從中找到 架構師之路 一本本查，要查到什麼時候去？於是，圖書管理員設計了一套規則 1 一樓放歷史類，二樓放文學類，三樓放it類 2 it類，又分軟體類，硬體類 3 軟體類，又按照書名音序排序 以便快速找到一本書。與之模擬，資料庫儲存了10...