數據庫查詢優化

索引設計優化：

• 爲了提升查詢速度提供的一種數據結構, 相似書的目錄, 方便快速查詢出數據, 而不是從頭至尾的依次比對

• 優勢

  • 增長查詢速度

  • 索引不只能夠提升精確查詢的速度, 還能夠提升排序和分組的效率

• 缺點

  • 增長數據庫的存儲空間

  • 減慢增刪改速度(索引須要隨之改變)

• 建立索引

create table t_user(
  id int not null,  
  mobile char(10) not null,
  key (mobile)  # 設置索引
) 

alter table t_user add nickname varchar(20);
alter table t_user add key (nickname);

查看索引： show keys from t_user;

查看查詢是否使用是索引：explain select * from t_user where nickname = 'zs';

 

二，索引分類：

• 主鍵索引

  • 建立主鍵後自動生成

• 惟一索引

  • 設置惟一約束後自動生成

• 外鍵索引

  • 設置外鍵約束後自動生成

• 普通索引 index

  • 不要用可空列做爲索引, 易出錯

  • 適合的字段

    • 常常出如今Where子句中的字段，特別是大表的字段，應該創建索引；

    • 常常與其餘表進行鏈接的表，在鏈接字段上應該創建索引；

    • 索引應該建在選擇性高(取值範圍廣)的字段上；

    • 頻繁進行數據操做的表，不要創建太多的索引；

  • 場景

    • 自定義的外鍵字段(邏輯外鍵)

    • 高選擇性, 查詢頻繁的接口

mysql的索引存儲結構爲B+tree結構，平衡二叉樹

聚簇索引:

• 葉子節點上存放的是數據行

• InnoDB引擎的主鍵索引使用這種存儲方式

• 二級/輔助索引(全部非主鍵索引)的葉子節點上存放的是主鍵值, 因此二級索引須要進行二次查詢

 

 

 非聚簇索引: 在葉子節點上存儲的是數據行的物理地址, 數據行和索引存儲在不一樣的結構中

 

 

 

多列/聯合索引

• 聯合索引必須符合最左原則, 不然無效

  • where mobile /where mobile and type會使用索引

  • where type 不會使用索引

create table t_user(
  id int not null,  # 非空約束
  mobile char(10) not null,
  type tinyint default 0,
  key k_mobile_type (mobile, type)  # 設置聯合索引
)    

key testindex (type, 姓, 名) 
select 姓, 名 from t_user where type = 1;

覆蓋索引

• 若是一個索引包含(或者說覆蓋)全部須要查詢的字段的值, 稱爲"覆蓋索引"

• 若是查詢觸發了覆蓋索引, 將直接從索引中提取出數據, 而不會再去查詢數據行

• 合理利用覆蓋索引機制, 極大的提升性能

• 應用場景

  • 分頁優化

  • 優化二次查詢

  • 提升or運算的查詢速度

create table t_user(
  id int auto_increment primary key,  
  name varchar(20) not null,
  age int default 0,
  key test_index (name, age)  # 設置聯合索引
)    

select age from t_user where name = 'zs';  # 使用覆蓋索引

5. 主鍵設計

• InnoDB的主鍵爲何選擇自增

  • 數據和主鍵索引是綁定在一塊兒的, 主鍵自增則會讓數據順序添加到B+Tree中, 不會因移動數據而影響插入速度

• 複合/聯合主鍵

  • 將多個業務鍵聯合定義爲主鍵

  • 優勢

    • 節省空間

  • 缺點

    • 不是自增, 性能差

    • 沒法做爲其餘表的外鍵

  • 儘可能不要用

   

6. 三範式和反範式設計 (重點)

• 規則

  • 第一範式: 字段具備原子性, 不可拆分

  • 第二範式: 依賴於所有主鍵, 而非部分主鍵

    • 主要針對複合主鍵,通常都會遵照

    • 好比某人的成績 由班級+姓名決定, 成績徹底依賴於班級+姓名, 可是班主任姓名只依賴於班級, 不依賴學生姓名, 則不能在該表中

  • 第三範式: 只依賴於主鍵, 非主鍵字段互不依賴

• 目的

  • 減小冗餘字段/重複的數據

---

• 回覆數/評論數/點贊數 均可以經過聚合查詢來獲取 select count(*) from t_comment group by news_id

• 若是單獨定義字段來記錄, 該字段就稱爲冗餘字段

• 這種設計稱爲 反範式設計

  • 經過加入冗餘字段/重複數據 來提升數據庫的查詢速度

  • 減小關聯查詢

  • 用空間換取時間

• 範式是武功招式, 如何運用全看本身

 

7. 數據庫引擎

• 實現數據存儲的不一樣解決方案

• InnoDB mysql5.5開始 默認

  • 支持事務(回滾/提交/ACID特性/多版本併發控制等)

    • 數據恢復可以使用事務日誌(undo/redo log), 恢復速度快

  • 支持行級鎖&表級鎖

    • 併發訪問時效率高

  • 支持外鍵約束

  • 插入/更新/主鍵查詢快

  • 須要內存和硬盤多

  • 常規推薦使用

• MyISAM

  • 不支持事務

  • 只支持表級鎖

  • 不支持外鍵約束

  • 批量插入/查詢/count( )速度快

  • 簡單, 適合小型項目/以批量插入和查詢爲主的系統(內部管理系統)

• 系統公告表選擇了MyISAM

  • 由於基本不會修改, 不存在大量併發寫操做, 也就不須要行級鎖提供併發能力

  • 和其餘表沒有關聯, 不須要事務提供原子性等支持

• 查詢多, MyISAM會更快

   

8. 字符集

• 字符集問題

  • utf-8若是保存數據中包含表情符號會崩潰

  • utf-8編碼最大字符長度爲3字節, 而unicode中大編碼實現的表情符號(emoji)爲4字節

  • 編碼方式須要設置爲utf8mb4

• sql註釋 COMMENT xxx

• show create table xx; / show full columns from test; 能夠顯示出註釋