mysql索引

時間 2019-11-10

標籤 mysql 索引欄目 MySQL 简体版

原文原文鏈接

實現效果：通俗的說索引是用來提升查詢效率，不須要經過掃描所有表記錄，而直接使用索引快速定位須要查詢的值。mysql

需求的影響：論壇帖子要求總量的統計，附加要求，實時更新
ios

功能上很是容易實現，執行select count * from 表名的query就能夠獲得結果，若是咱們採用不是MyLSAM存儲引擎，而是使用Innodb的存儲引擎，那麼存放帖子的表有上千萬條記錄，執行這條須要很大的成本。
web

沒有where的count使用MyLSAM要比InnoDB快的多，由於MyLSAM內置了一個計時器，count時他直接從計數器中讀，1而InnoDB必須掃描全表。在InnoDB上執行count是通常要伴隨where，且where重要包含主鍵之外的索引列。
sql

這樣查詢不行，咱們就專門爲這個功能建一個表，就只有一個字段，一條記錄，就存放這個統計量，每次有新的帖子產生的時候，都將這個值增長1，咱們每次都只須要查詢這個表就能夠獲得結果，效率就能知足要求。查詢效率確定可以知足要求，開始若是帖子產生快，高峯時期能夠每秒上百個新增操做。由於鎖資源爭用嚴重形成總體性能的大幅度降低。
數據庫

經過建立一個統計表，而後經過一個定時任務每隔必定時間段去更新一次裏面的統計值，既能夠解決統計值查詢的效率問題，有保證不影響新發帖的效率。
性能優化

系統架構及實現的影響
服務器

全部數據都不是適合在數據庫存放。
網絡

二進制多媒體數據：主要包括圖片，音頻，視頻和其餘一些相關的二進制文件，將二進制多媒體數據存放在數據庫中，數據庫空間只有消耗嚴重，數據存儲消耗數據庫主機的CPU資源。
mysql優化

超大文本數據
數據結構

在5.0.3以前的mysql版本，VARCHAR類型的數據最長只能存放255個字節，若是須要存儲更長的數據到一個字段，必須使用TEXT類型（最大可存放64k）的字段，甚至是更大的LONGTEXT類型（最大4GB）。而text類型數據的處理性能要遠比VARCHAR類型數據的處理性能底下不少。從5.0.3版本，VARCHAR類型的最大長度被調整到64kb了，因此，超大文本數據存放的數據庫綜合那個不只會帶來性能低下，還帶來空間佔用浪費。

對於web應用，活躍數據的數據量老是不會特別大，有些活躍數據更是不多變化，對於這裏數據，若是咱們能將變化相對較少的部分活躍數據經過應用層的cache機制cache到內存中，對性能提高確定是成數量級的，並且因爲是活躍數據，對系統總體的性能影響也會很大。

查詢語句對性能的影響

數據庫管理軟件中，最大的性能瓶頸是在於磁盤io，就是數據存取操做上面，對同一份數據，以不一樣方式找到其中的某一點內容的時候，所需的數據量可能會有天壤之別，消耗的資源也區別不少。

explain來查看執行計劃

profiling來查看實際執行計劃

經過執行show PROFILE命令獲取當前系統中保存的多個query的profile的概要信息。

數據庫Schema設計對性能的影響

硬件選擇對性能的影響

數據庫主機是存取數據的地方，數據庫主機的io性能確定是須要最優先考慮的一個因素，無論什麼類型的數據庫應用都適用。在主機中決定io性能不只主要有磁盤和內存所決定，固然也包括各類io相關的板卡

其次，數據庫主機是存取數據的地方，詞語要相對集中不少，單臺主機上所須要進行的計算量天然也就比較多，全部數據庫主機的CPU處理能力也不能忽視

數據庫負責數據的存儲，與各應用茨城縣的交互中傳遞的數據比其餘各種服務器都要多，因此數據庫主機的網絡設備的性能也可能會成爲系統的瓶頸。

數據庫應用系統的優化，其實是一個須要多方面配合，多方面優化的才能產生根本性改善的事情。

能夠經過商業需求合理化，系統架構最優化，邏輯實現荊建華，硬件設施理性化。

mysql性能優化之一-索引

mysql索引的好處：對於沒有索引的表，單表查詢可能幾十萬數據的瓶頸，而一般大型網站單日就會產生幾百萬的數據，沒有索引查詢會變得很是緩慢。

索引實在存儲引擎中實現的，而不是在服務器層中實現的。每種存儲的索引都不必定徹底相同，並非全部的存儲引擎都支持全部的索引類型。

什麼是索引：

是幫助mysql高興獲取數據的數據結構，他的存在形式是文件，縮影可以幫助咱們快速定位數據。

爲何使用索引：

索引可讓mysql高效運行，能夠提升mysql的插敘效率，數據約束

好處：

提升查詢效率，快速定位數據

索引產生的代價：

1，自己以文件形式存放在硬盤，須要的時候才加載至內存，全部添加索引會增長磁盤的開銷；

2，寫數據：須要更新索引，歲數據庫是不少的開銷，見底表更新，添加和刪除的速度。

不建議使用索引的狀況有哪些：

表記錄少

索引的選擇性較低。指不重複的索引值與表記錄數的比值，取值範圍0到1，值越大，選擇性越大

索引的類型：

普通索引，基本的索引，沒有任何限制

create index index_name on tablename（column1）

惟一索引，與普通索引相似，不一樣的就是索引列的值必須惟一，但容許空值，空值值null，組合索引的組合列的值必須惟一

create uniaue table_name on tablename（column1）

主鍵索引，一種特殊的惟一索引，不容許有空值，通常在建表的時候同時創建主鍵索引

create table table_name（id int not unll，username varchar（16） not null，primay key（id））；

組合索引，創建單列索引，表明有3個單列索引，查詢時和上述的組合索引效率也會大不同，遠遠低於組合索引。

全文索引，只用於mylsam表，對文本域進行索引，字段類型包括char，varchar，text，不過對於大容量的數據表，生成全文索引是一個很是消耗時間硬盤空間的作法

create fulltext index index_name on tablename（column）

索引的數據結構，B-tree索引結構：

如上圖，是一顆b+樹，這裏只說一些重點，淺藍色的塊咱們稱之爲一個磁盤塊，能夠看到每一個磁盤塊包含幾個數據項（深藍色所示）和指針（×××所示），如磁盤塊1包含數據項17和35，包含指針P1、P2、P3，P1表示小於17的磁盤塊，P2表示在17和35之間的磁盤塊，P3表示大於35的磁盤塊。真實的數據存在於葉子節點即3、5、9、10、13、15、28、29、36、60、75、79、90、99。非葉子節點只不存儲真實的數據，只存儲指引搜索方向的數據項和指針，如17、35並不真實存在於數據表中。

b+樹的查找過程

如圖所示，若是要查找數據項29，那麼首先會把磁盤塊1由磁盤加載到內存，此時發生一次IO，在內存中用二分查找肯定29在17和35之間，鎖定磁盤塊1的P2指針，內存時間由於很是短（相比磁盤的IO）能夠忽略不計，經過磁盤塊1的P2指針的磁盤地址把磁盤塊3由磁盤加載到內存，發生第二次IO，29在26和30之間，鎖定磁盤塊3的P2指針，經過指針加載磁盤塊8到內存，發生第三次IO，同時內存中作二分查找找到29，結束查詢，總計三次IO。真實的狀況是，3層的b+樹能夠表示上百萬的數據，若是上百萬的數據查找只須要三次IO，性能提升將是巨大的，若是沒有索引，每一個數據項都要發生一次IO，那麼總共須要百萬次的IO，顯然成本很是很是高。