mysql 主表某一列 小于某一个表的两列之和_关于MySQL索引知识与小妙招
1.1 索引的優點
1.2 索引的用處
1.3 索引的分類
數據庫會默認創建索引,但是并不是給主鍵建立索引,而是給唯一鍵建立索引的,因為主鍵的特性是唯一且非空
- 主鍵索引: 是一種特殊的唯一索引,不允許有空值。(主鍵約束,就是一個主鍵索引)
- 唯一索引: 索引列中的值必須是唯一的,但是允許為空值。
- 普通索引: MySQL中基本索引類型,沒有什么限制,允許在定義索引的列中插入重復值和空值,純粹為了查詢數據更快一 點。
- 全文索引: 只有在MyISAM引擎上才能使用,只能在CHAR,VARCHAR,TEXT類型字段上使用全文索引什么是全文索引,就是在一堆文字中,通過其中的某個關鍵字等,就能找到該字段所屬的記錄行,比如有"LOL LPL 牧小農" 通過牧小農,可能就可以找到該條記錄。這里說的是可能,因為全文索引的使用涉及了很多細節,我們只需要知道這個大概意思。一般開發中,不會用到全文索引,因為其占用很大的物理空間和降低了記錄修改性,故較為少用。
- 組合索引: 在表中的多個字段組合上創建的索引,只有在查詢條件中使用了這些字段的左邊字段時,索引才會被使用,使用組合索引時遵循最左前綴集合。例如這里由id、name和age3個字段構成的索引,索引行中就按id/name/age的順序存放,索引可以索引下面字段組合(id,name,age)、(id,name)或者(id)。如果要查詢的字段不構成索引最左面的前綴,那么就不會使用索引,比如,age或者(name,age)組合就不會使用索引查詢。
1.4 面試技術名詞
- 回表: 數據庫根據索引(非主鍵)找到了指定的記錄所在行后,還需要根據主鍵再次到數據塊里獲取數據,這種稱之為回表
- 覆蓋索引: 看我寫的一篇文章:面試三輪我倒在了一道sql題上——sql性能優化
- 最左匹配: 指在聯合索引中,如果你的 SQL 語句中用到了聯合索引中的最左邊的索引,那么這條 SQL 語句就可以利用這個聯合索引去進行匹配,如果遇到范圍查詢(>、select * from t where a=1 and b=1 and c =1; #這樣可以利用到定義的索引(a,b,c),用上a,b,c
select * from t where a=1 and b=1; #這樣可以利用到定義的索引(a,b,c),用上a,b
select * from t where b=1 and a=1; #這樣可以利用到定義的索引(a,b,c),用上a,c(mysql有查詢優化器)
select * from t where a=1; #這樣也可以利用到定義的索引(a,b,c),用上a
select * from t where b=1 and c=1; #這樣不可以利用到定義的索引(a,b,c)
select * from t where a=1 and c=1; #這樣可以利用到定義的索引(a,b,c),但只用上a索引,b,c索引用不到 - 索引下推: 稱為 Index Condition Pushdown (ICP),這是MySQL提供的用某一個索引對一個特定的表從表中獲取元組”,注意我們這里特意強調了“一個”,這是因為這樣的索引優化不是用于多表連接而是用于單表掃描,確切地說,是單表利用索引進行掃描以獲取數據的一種方式。
1.5 索引采用的數據結構
1.5.1 哈希表
缺點︰
1、利用hash存儲的話需要將所有的數據文件添加到內存,比較耗費內存空間
2、如果所有的查詢都是等值查詢,那么hash確實很快,但是在企業或者實際工作環境中范圍查找的數據更多,而不是等值查詢,因此hash就不太適合了
1.5.2 二叉樹
缺點∶
無論是二叉樹還是紅黑樹,都會因為樹的深度過深而造成io次數變多,影響數據讀取的效率
1.5.3 B+樹
B樹特點:
1、所有鍵值分布在整棵樹中
2、搜索有可能在非葉子結點結束,在關鍵字全集內做一次查找,性能逼近二分查找
3、每個節點最多擁有m個子樹
4、根節點至少有2個子樹
5、分支節點至少擁有m/2顆子樹(除根節點和葉子節點外都是分支節點)
6、所有葉子節點都在同一層、每個節點最多可以有m-1個key,并且以升序排列
實例圖說明∶
每個節點占用一個磁盤塊,一個節點上有兩個升序排序的關鍵字和三個指向子樹根節點的指針,指針存儲的是子節點所在磁盤塊的地址。兩個關鍵詞劃分成的三個范圍域對應三個指針指向的子樹的數據的范圍域。以根節點為例,關鍵字為16和34,P1指針指向的子樹的數據范圍為小于16,P2指針指向的子樹的數據范圍為16~34 ,P3指針指向的子樹的數據范圍為大于34。
查找關鍵字過程:
缺點:
- 每個節點都有key,同時也包含data,而每個頁存儲空間是有限的,如果data比較大的話會導致每個節點存儲的k ey數量變小
- 當存儲的數據量很大的時候會導致深度較大,增大查詢時磁盤io次數,進而影響查詢性能
1.6 索引匹配方式
全值匹配: 全值匹配指的是和索引中的所有列進行匹配
explain select * from staffs where name = 'July' and age = '23' and pos = 'dev';1匹配最左前綴: 只匹配前面的幾列
explain select * from staffs where name = 'July' and age = '23';explain select * from staffs where name = 'July';123匹配列前綴: 可以匹配某一列的值的開頭部分
explain select * from staffs where name like 'J%';explain select * from staffs where name like '%y';123匹配范圍值: 可以查找某一個范圍的數據
explain select * from staffs where name > 'Mary';1**精確匹配某一列并范圍匹配另外一列:**可以查詢第一列的全部和第二列的部分
explain select * from staffs where name = 'July' and age > 25;1只訪問索引的查詢: 查詢的時候只需要訪問索引,不需要訪問數據行,本質上就是覆蓋索引
explain select name,age,pos from staffs where name = 'July' and age = 25 and pos = 'dev';1二、哈希索引
- 基于哈希表的實現,只有精確匹配索引所有列的查詢才有效
- 在mysql中,只有memory的存h值,所以索引的結構十分緊湊,這讓哈希索引查找的速度非常快
2.1 哈希索引的限制
2.2 案例
當需要存儲大量的URL,并且根據URL進行搜索查找,如果使用B+樹,存儲的內容就會很大:select id from url where url=""
也可以利用將url使用CRC32做哈希,可以使用以下查詢方式:select id fom url where url="" and url_crc=CRC32("")
此查詢性能較高原因是使用體積很小的索引來完成查找
三、組合索引
當包含多個列作為索引,需要注意的是正確的順序依賴于該索引的查詢,同時需要考慮如何更好的滿足排序和分組的需要
案例: 建立組合索引 a,b,c ,不同SQL語句使用索引情況
語句索引是否發揮作用where a=3是,只使用了awhere a=3 and b=5是,使用了a,bwhere a =3 and b = 5 and c= 4是,使用了a,b,cwhere a = 3 or c = 4否where a = 3 and c= 4是,僅使用了awhere a = 3 and b > 10 and c = 7是,使用了a,bwhere a = 3 and b like ‘%mxn%’ and c=7使用了a
四、聚簇索引與非聚簇索引
4.1 聚簇索引
- 不是單獨的索引類型,而是一種數據存儲方式,指的是數據行跟相鄰的鍵值緊湊的存儲在一起,將數據存儲與索引放到了一塊,找到索引也就找到了數據
- 如果沒有定義主鍵,InnoDB會選擇一個唯一的非空索引代替。如果沒有唯一索引,InnoDB會隱式定義一個主鍵來作為聚簇索引。InnoDB 只聚集在同一個頁面中的記錄。包含相鄰健值的頁面可能相距甚遠。
4.2 非聚簇索引
- 數據文件跟索引文件分開存放,將數據存儲于索引分開結構,索引結構的葉子節點指向了數據的對應行,myisam通過key_buffer把索引先緩存到內存中,當需要訪問數據時(通過索引訪問數據),在內存中直接搜索索引,然后通過索引找到磁盤相應數據,這也就是為什么索引不在key buffer命中時,速度慢的原因
- 通過葉子節點指針找到數據頁中的數據,所以非聚簇索引是邏輯順序
五、覆蓋索引
5.1 基本介紹
5.2 優勢
1、索引條目通常遠小于數據行大小,如果只需要讀取索引,那么mysql就會極大的較少數據訪問量
2、因為索引是按照列值順序存儲的,所以對于IO密集型的范圍查詢會比隨機從磁盤讀取每一行數據的IO要少的多
3、一些存儲引擎如MYISAM在內存中只緩存索引,數據則依賴于操作系統來緩存,因此要訪問數據需要一次系統調用,這可能會導致嚴重的性能問題
4、由于INNODB的聚簇索引,覆蓋索引對INNODB表特別有用
5.3 案例演示
1、當發起一個被索引覆蓋的查詢時,在explain的extra列可以看到using index的信息,此時就使用了覆蓋索引
2、在大多數存儲引擎中,覆蓋索引只能覆蓋那些只訪問索引中部分列的查詢。不過,可以進一步的進行優化,可以使用innodb的二級索引來覆蓋查詢。
例如:actor使用innodb存儲引擎,并在last_name字段又二級索引,雖然該索引的列不包括主鍵actor_id,但也能夠用于對actor_id做覆蓋查詢
六、優化小細節
- 當使用索引列進行查詢的時候盡量不要使用表達式,把計算放到業務層而不是數據庫層
- 盡量使用主鍵查詢,而不是其他索引,因為主鍵查詢不會觸發回表查詢
- 使用前綴索引有時候需要索引很長的字符串,這會讓索引變的大且慢,通常情況下可以使用某個列開始的部分字符串,這樣大大的節約索引空間,從而提高索引效率,但這會降低索引的選擇性,索引的選擇性是指不重復的索引值和數據表記錄總數的比值,范圍從1/#T到1之間。索引的選擇性越高則查詢效率越高,因為選擇性更高的索引可以讓mysql在查找的時候過濾掉更多的行。
一般情況下某個列前綴的選擇性也是足夠高的,足以滿足查詢的性能,但是對應BLOB,TEXT,VARCHAR類型的列,必須要使用前綴索引,因為mysql不允許索引這些列的完整長度,使用該方法的訣竅在于要選擇足夠長的前綴以保證較高的選擇性,通過又不能太長。
- 使用索引掃描來排序mysql有兩種方式可以生成有序的結果:通過排序操作或者按索引順序掃描,如果explain出來的type列的值為index,則說明mysql使用了索引掃描來做排序
掃描索引本身是很快的,因為只需要從一條索引記錄移動到緊接著的下一條記錄。但如果索引不能覆蓋查詢所需的全部列,那么就不得不每掃描一條索引記錄就得回表查詢一次對應的行,這基本都是隨機IO,因此按索引順序讀取數據的速度通常要比順序地全表掃描慢
? mysql可以使用同一個索引即滿足排序,又用于查找行,如果可能的話,設計索引時應該盡可能地同時滿足這兩種任務。
? 只有當索引的列順序和order by子句的順序完全一致,并且所有列的排序方式都一樣時,mysql才能夠使用索引來對結果進行排序,如果查詢需要關聯多張表,則只有當orderby子句引用的字段全部為第一張表時,才能使用索引做排序。order by子句和查找型查詢的限制是一樣的,需要滿足索引的最左前綴的要求,否則,mysql都需要執行順序操作,而無法利用索引排序 - union all,in,or都能夠使用索引,但是推薦使用in
- 范圍列可以用到索引,范圍條件是:,范圍列可以用到索引,但是范圍列后面的列無法用到索引,索引最多用于一個范圍列
- 強制類型轉換會全表掃描
- 更新十分頻繁,數據區分度不高的字段上不宜建立索引更新會變更B+樹,更新頻繁的字段建議索引會大大降低數據庫性能.
類似于性別這類區分不大的屬性,建立索引是沒有意義的,不能有效的過濾數據,
一般區分度在80%以上的時候就可以建立索引,區分度可以使用 count(distinct(列名))/count(*) 來計算
總結
以上是生活随笔為你收集整理的mysql 主表某一列 小于某一个表的两列之和_关于MySQL索引知识与小妙招的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 移动端网页打印代码_WEB移动端怎么是实
- 下一篇: android 缩略图uri_课题_an