部落格位址僅此而已。回憶一下當時的想法真的很可笑，老是喜歡搞一些表面的東西，實際上當時的部落格對自己的收穫微乎其微，純屬為了
寫而寫。現在呢，實習快半年了，實習期間做了很多事情，但是回想自己的收穫，的確有進步，是什麼說不出來。參加實習的這段時間
以來，每天在公司待到十點學習新的知識，從來不曾懈怠，可是學過一遍留下的不多。現在回想一下問題在哪：沒計畫，從來都沒有認
真的給自己定過乙個學習計畫，想到什麼學什麼。這幾天一直想重新開始寫自己的部落格，每隔幾天總結總結收穫，梳理一遍，查缺補漏，
再記錄下每天的學習計畫。堅持讓明天的自己比今天更強。
正式開始。
舉個栗子：
create table test_index(
id int(10) not null auto_increment primary key,
name varchar(10) not null,
group_name varchar(10) not null,
address varchar(10) not null,
balabala varchar(10),
key(name,group_name,address)
);
這裡主要以innodb為主
hash索引
全文索引
b+tree結構——（待續）
b+tree索引中的值都是順序儲存，操作的基本單位是頁，預設一頁大小為16k。b+tree索引會有聚簇索引與二級索引兩種儲存方式，聚簇索引會按照資料行的大小順序儲存在頁內(最常用的聚簇索引就是主鍵)，同一頁中的資料都是相鄰的，但是相鄰頁在實體地址中的儲存可能就相隔甚遠。
innodb如何選擇聚簇索引？1.當建表的時候定義了主鍵，那主鍵就作為聚簇索引。2.如果沒有主鍵被定義，那麼該錶的第乙個唯一非空索引被作為聚集索引。3。如果前兩者都沒有，innodb會選擇生成乙個隱藏的主鍵來作為聚簇索引。
二級索引也是按值排序，但是同一頁的資料在實體地址中並不相鄰，二級索引葉子結點中存的是主鍵，所以在使用二級索引會先在二級索引上找到指定的主鍵，再通過主鍵索引（主鍵索引中存頁指標）查詢資料行，存在乙個二次查詢的問題。
一條using index sql的查詢過程：
索引的優點
建立合適的索引
在varchar型別的字段上建立索引（text，blob只可以建字首索引），有時候通過整個字串建立索引並不是明智的選擇，因為字串較長，一頁內可以存放的資料減少，相應的io次數會增加，此時可以建立字首索引，利用字串的前n位建索引，字首的長度n應該滿足count(distinct,left(字段，n))/count(*)約等於count(distinct,字段)/count(*)索引的基數接近於完整列的基數。
還有一種辦法利用hash索引，innodb不支援hash索引（innodb的自適應性hash索引，由innodb自動建立，開發者無法干預），建立偽hash索引，利用crc32(),sha1(),md5(),作為hash函式。再利用hash列建立索引，通過hash等值比較，等位資料行，避免過大的varchar完整列做索引。
每個列上都建立索引（誤區）。
合適的索引列順序，正常狀況下選擇性高的列排前邊。
mysql索引學習總結
最近用到mysql索引，趕緊了解了一下，最後做乙個小小的總結。索引，就是按照索引排好序的資料結構，查詢資料的時候走索引比不走索引要快很多，因為不走索引意味著全表掃瞄，而且還可能會鎖住元組，效率比較低。mysql使用b tree的索引模型，無論是myisam還是innodb。為什麼使用b 樹而不是紅黑...
mysql索引學習總結
優勢 劣勢 索引也是一張表，該錶儲存了主鍵與索引字段，並指向實體表的記錄，所以索引也是占用空間的 雖然提高了查詢速度，但是會降低更新表的速度，如果對錶進行insert update 和delete。因為更新表，不僅要儲存資料，還要儲存一下索引檔案每次更新新增了索引列的字段，都會調整更新帶來的兼職變化...
mysql 索引總結 mysql索引總結
mysql中每乙個表都有乙個聚簇索引clusted index，該所索引是預設建立的，除此之外的表上的每乙個非聚簇索引都是二級索引，又叫輔助索引 secondary indexes 以innodb來說，每個innodb表具有乙個特殊的索引稱為聚集索引，如果您的表上定義有主鍵，該主鍵索引是聚集索引，如...