數據庫優化

Mysql 的索引’

概述：索引就是編號，添加索引後，查詢效率會提升，增刪改效率會相對下降

分類：普通索引

惟一索引：咱們之前用的主鍵約束，惟一約束就是倆個比較特殊的惟一索引

建立普通索引

create index 索引名 on 數據表名（字段名（長度））；

建立惟一索引：

create unique index 索引名 on 數據表名（字段名（長度））

刪除索引 ：alter table 數據表名 drop index 索引名 //刪除普通索引

alter table 數據表名 drop primary key; //刪除主鍵索引

顯示索引信息

show index from 數據表名

事務的概述:

事務指的是邏輯上的一組操做,組成該操做的各個邏輯單元,要麼所有成功,要麼所有失敗

事務的特色:ACID

原子性 :事務的各個邏輯單元已經是最小單位,不可繼續分割

一致性:事務執行先後的數據應該保持一致

隔離性: 一個事務執行的過程當中不受其餘事務的干擾

持久性:事務執行完以後 結果應持久化到數據表中,進行永久存儲

效率從高到低分別是:

read unconmmitted>read committed >repeatable read >serializable

隔離級別:

serializable >repeatable read > read committed > read uncommitted

事務控制語句:

begin 或者 start transaction   //開啓事務

commit  //提交事務

rollback // 回滾事務

sql 操做事務的流程

1. 開啓事務

begin 或者 start transaction

1. 執行相關操做

例如

先執行 50% -->保存一個節點(savepoint)

再接着執行 25% -->保存一個節點

最後在執行25%的時候,發現前25%執行錯誤, 若是採用rollback回滾事務會致使效率下降 ,能夠經過恢復節點的方式進行處理將數據恢復到執行完50%節點上,而後執行剩下的倆個25%

3)提交事務,若是整條SQL語句執行都有問題,能夠選擇回滾事務

mysql 使用事務時可能遇到的問題

1)多個事務併發執行,會致使(髒讀, 不可重複讀,  虛讀)

2)事務在運行過程當中被強行中止

不考慮隔離性的問題和解決方案

髒讀:  讀未提交  一個事務讀取到另外一個事務還沒來得及提交的數據

不 可重複讀: 讀已提交  一個事務讀取到另外一個事務已經提交的修改數據 致使倆次查詢結果不一致

虛讀 :一個事務讀取到了另外一個事務已經提交的添加的數據 致使倆次查詢結果不一致

串行化讀取:

一個事務A在操做某一張表的時候,另外一個事務必須等待A操做完畢後草能夠操做該表

四大隔離性:

read uncommitted :讀未提交 可能發生髒讀 不可重複讀 ,虛讀

read committed : 讀已提交 能規避髒讀, 可能發生不可重複讀 虛讀

repeatable read : 可重複讀 能規避 髒讀 不可重複讀 可能發生虛讀

serializable  能規避髒讀, 不可重複讀 虛讀

mysql 的封鎖

排它鎖 //x鎖 :可讀可寫 一個事務對錶加了X鎖 其它事務必須等到該事務操做完這張表後,才能夠対這張表操做

共享鎖 ://S 鎖  只讀 多個事務能夠同時對麼一張表加共享鎖

活鎖 // 有概率解開  某個事務在永遠等待的狀態,得不到封鎖的機會 這種現象稱爲活鎖

死鎖 :確定解不開  倆個或倆個以上的事務都處於等待狀態每一個事務都在等待對方事務接觸封鎖 這樣任何事務都處於等待狀態而沒法繼續執行的現象稱爲死鎖

mysql的目錄結構

/etc/my.cnf       //這是mysql的主配置文件  Linux 操做系統中後綴名是.cnf window 系統中是.ini

/var/lib/mysql    //mysql中數據庫及數據存儲的目錄

/var/log/mysql   //數據庫的日誌文件存放目錄   該路徑也多是/var/lib/mysql

netstat  -nltp  //查看端口

//ps -ef | grep mysql  //查看全部課mysql 相關的進程

數據庫分類

關係型數據庫 : mysql  Oracle  sqlserver

非關係型數據庫 :redis hbase 等

數據庫設計流程:

1. 需求分析: 明確客戶需求 到底作什麼?

2. 概念模型設計 : 該階段是整個數據庫設計的關鍵 它經過對用戶需求進行綜合,概括 與抽象 主要是經過E-R圖表示

優勢 :簡潔明瞭 描述了各個表之間的邏輯關係 獨立於計算機與具體的RDBMS無關

3)邏輯模型設計 :與具體的數據庫相關,反應業務部門的

4)數據庫實施: 建立數據庫 定義數據庫結構 組織數據入庫 調試數據庫並進行數據庫的試運行

5)數據庫的運行和維護 :數據庫正式運行以後對數據庫運行過程當中對其進行評價 調整 修改 調優等

數據庫設計遵循的原則

範式 就是符合某一規範級別的關係模式的集合 共有7種範式

第一範式 :每一個屬性都是不可分割的

第二範式: 主屬性(主鍵)和 非主屬性 直接依賴

第三範式 : 主屬性(主鍵) 和非主屬性 間接依賴

優勢

1)範式主要說明的就是:設計表的時候,擴展拆分(分離)程度

1. 範式越高,會讓擴展的程度變得更好

缺點:編寫sql 語句時會變得更加的繁瑣

爲何要進行數據庫的優化

1)避免網站頁面出現訪問錯誤

因爲數據庫鏈接超時產生頁面錯誤,因爲慢查詢形成頁面沒法加載

2)增長數據庫的穩定性

很對數據庫問題都是因爲低效的查詢引發的

3)優化用戶體驗

    流暢頁面的訪問速度

     良好的功能體驗

數據庫優化的方案

優化"成本"從低到高分別爲 :

Sql 語句及索引 --> 數據表結構--> 系統配置-->硬件

1)sql 及索引優化

  根據需求寫出良好的sql 並建立有效的索引 ,實現一種需求可有多種寫法 這時候咱們就須要選擇一種效率高的寫法 這個時候就須要Sql 優化

2)數據庫表結構優化 

根據數據庫的範式,設計表結構 ,表結構設計的好壞直接關係到寫SQL語句

3)系統配置的優化

     大多數運行在Linux機器上 ,如tcp 鏈接數的限制, 打開文件數的限制,安全性的限制,所以咱們要對這些配置進行相應的優化

 4)硬件配置優化

選擇合適數據庫服務的cpu 更快的io   更高的內存 

如何發現有問題的sql

mysql 提供了慢查詢日誌查看功能,能夠幫助查看某一條sql語句執行的一些狀態

查看mysql 是否開啓慢查詢日誌

show variables like '%slow %'  //默認是關閉狀態

啓用mysql 的慢查詢日誌功能

set global log queries not using_indexes=on // 將不使用索引的慢查詢日誌進行記錄

set global slow_query_log=on // 開啓慢查詢日誌

show variables like '%slow%'// 查看慢查詢日誌存儲的位置

set global long_query_time=1 //大於1秒鐘的數據記錄到慢日誌中 若是設置爲默認0 則會有大量的信息存貯在磁盤中,磁盤很容易滿掉

監聽日誌文件,看是否寫入 若是本身不當心刪除了 log 日誌文件 重啓下mysql 服務 而後從新登陸便可 service mysql restart

如何經過慢查詢日誌發現有問題的sql

a)查詢次數多且每次查詢佔用時間長的sql

b) Io大的sql :掃描的行數越多,IO 越大

c) 未命中索引的sql

explain 關鍵字: 

sql 的執行計劃 側面反映出了sql的執行效率  具體的執行方式是隻須要在執行的sql前面加上explain 關鍵字便可

用法 : explain select *from film ; // 查看指定 sql的執行效率 (橫向排列)

explain  select * from film \g  // 查看指定的sql 的執行效率 (縱向排列)

名詞解釋:

table :顯示這一行的數據是關於哪張表的

type : 這是重要的列,顯示鏈接使用了何種類型 鏈接類型從最好到最差分別爲

const >eq_reg >ref >range >index 和all  

possible_keys 顯示可能應用在這張表中的索引

key:實際使用的索引,若是爲null則沒使用索引

key_len 使用索引的長度 ,在不損失精確性的狀況下,長度越短越好

ref:顯示索引的那一列被使用了

rows: mysql 認爲必須檢查的用來返回請求數據的行數

總結: 咱們重點關注的是type(儘量不要查詢整張表) key (儘量使用索引).rows_(行數不能太大,儘量下降掃描次數)

聚合函數的優化方案 : 經過加索引的方式實現優化  而後執行查詢語句 索引是順序操做的 不須要掃描表,執行效率就會比較恆定

子查詢的優化

子查詢 是咱們在開發過程當中常用的一種方式,在一般狀況下 須要把子查詢優化爲join查詢 但在優化時 須要注意是否有一對多的關係 要注意重複數據  注: 在編寫代碼的時候,若是使用子查詢可能會比多表鏈接查詢更加的簡單 因此在開發階段可使用子查詢 只要能知足須要就能夠但在正式上線商業化使用的時候,儘量將子查詢更改成join查詢會更好一點 join查詢的效率要比子查詢的效率更高  建議:能夠先用子查詢實現功能,而後後期再優化爲鏈接查詢便可

group by 分組優化 :先分組

limit 查詢的優化

select film_id,description from where film_id>=150 and film_id<155  oder by film_id limit 150 ,5; 掃描行數不變, 執行計劃很 固定,效率也是很固定的 

注意 :主鍵要順序排序並連續的 若是主鍵中缺了某一列 或者某 幾列 會出現數據不足5行的數據 若是不連續,創建一個附加的index_id 列 保證這一列數據要自增的,並添加索引便可

總結: 儘量避免文件排序 和row的掃描(越少越好)由於這倆種操做都會增長IO的操做 從而下降sql語句的效率.