Schema的优化和索引 - 高性能的索引策略 - 聚簇索引(Clustered Indexes)
2009-09-02 00:00:00 来源:WEB开发网 闂傚倸鍊搁崐鎼佸磹閹间礁纾归柟闂寸绾惧綊鏌熼梻瀵割槮缁炬儳缍婇弻鐔兼⒒鐎靛壊妲紒鐐劤缂嶅﹪寮婚悢鍏尖拻閻庨潧澹婂Σ顔剧磼閻愵剙鍔ょ紓宥咃躬瀵鎮㈤崗灏栨嫽闁诲酣娼ф竟濠偽i鍓х<闁诡垎鍐f寖闂佺娅曢幑鍥灳閺冨牆绀冩い蹇庣娴滈箖鏌ㄥ┑鍡欏嚬缂併劎绮妵鍕箳鐎n亞浠鹃梺闈涙搐鐎氫即鐛崶顒夋晬婵絾瀵ч幑鍥蓟閻斿摜鐟归柛顭戝枛椤牆顪冮妶搴′簼缂侇喗鎸搁悾鐑藉础閻愬秵妫冮崺鈧い鎺戝瀹撲礁鈹戦悩鎻掝伀缁惧彞绮欓弻娑氫沪閹规劕顥濋梺閫炲苯澧伴柟铏崌閿濈偛鈹戠€n€晠鏌嶆潪鎷屽厡闁汇倕鎳愮槐鎾存媴閸撴彃鍓卞銈嗗灦閻熲晛鐣烽妷褉鍋撻敐搴℃灍闁绘挻娲橀妵鍕箛闂堟稐绨肩紓浣藉煐濮樸劎妲愰幘璇茬闁冲搫鍊婚ˇ鏉库攽椤旂》宸ユい顓炲槻閻g兘骞掗幋鏃€鐎婚梺瑙勬儗閸樺€熲叺婵犵數濮烽弫鍛婃叏椤撱垹纾婚柟鍓х帛閳锋垶銇勯幒鍡椾壕缂備礁顦遍弫濠氱嵁閸℃稒鍊烽柛婵嗗椤旀劕鈹戦悜鍥╃У闁告挻鐟︽穱濠囨嚃閳哄啰锛滈梺褰掑亰閸欏骸鈻撳⿰鍫熺厸閻忕偟纭堕崑鎾诲箛娴e憡鍊梺纭呭亹鐞涖儵鍩€椤掑啫鐨洪柡浣圭墪閳规垿鎮欓弶鎴犱桓闂佸湱枪閹芥粎鍒掗弮鍫熷仺缂佸顕抽敃鍌涚厱闁哄洢鍔岄悘鐘绘煕閹般劌浜惧┑锛勫亼閸婃牠宕濋敃鈧…鍧楀焵椤掍胶绠剧€光偓婵犱線鍋楀┑顔硷龚濞咃絿妲愰幒鎳崇喓鎷犻懠鑸垫毐闂傚倷鑳舵灙婵炲鍏樺顐ゆ嫚瀹割喖娈ㄦ繝鐢靛У绾板秹寮查幓鎺濈唵閻犺櫣灏ㄥ銉р偓瑙勬尭濡繂顫忛搹鍦<婵☆垰鎼~宥囩磽娴i鍔嶉柟绋垮暱閻g兘骞嬮敃鈧粻濠氭偣閸パ冪骇鐎规挸绉撮—鍐Χ閸℃ê闉嶇紓浣割儐閸ㄥ墎绮嬪澶嬪€锋い鎺嶇瀵灝鈹戦埥鍡楃仯闁告鍕洸濡わ絽鍟崐鍨叏濡厧浜鹃悗姘炬嫹

核心提示: 要注意主键是自增的,第二个例子的表命名为userinfo_uuid,Schema的优化和索引 - 高性能的索引策略 - 聚簇索引(Clustered Indexes)(6),和userinfo唯一的区别就是主键是UUID的,CREATE TABLE userinfo_uuid (uuid var
要注意主键是自增的。
第二个例子的表命名为userinfo_uuid。和userinfo唯一的区别就是主键是UUID的。
CREATE TABLE userinfo_uuid (
uuid varchar(36) NOT NULL,
我们对两个表做基准测试。首先我们对两个表插入100W数据。这个时候有足够的内存来存放索引。第二次我们插入300W数据,索引已经超出了内存的大小了。如下就是两个数据的比较
我们发现UUID作为主键的表不仅插入速度慢,而且索引还非常的大。一些原因是由于主键变大,而另一些原因不用怀疑的就是页的分裂和产生的一些碎片。
为了说明为什么会这样,让我们来看看当我们插入第一张表的时候,在索引中发生了些什么状况。
因为新行的主键并不是必须的比前一个主键值要大,因此InnoDB不能总是把新行放到这个索引之后。必须要为新行找到一个合适的位置-平均位置,也就是在靠近已存在数据的中部为新的数据生成一个空间。这就导致了一些额外的工作以及不理想的数据布局。下面就是一些缺陷:
1.目标页要刷新到硬盘并且要清除缓存。这个例子中,InnoDB在插入新行之前,要找到它和从硬盘中读取它。这就导致了很多的随机IO。
2.InnoDB有的时候会分裂页,这样做的目的是为新行创建空间。这需要移动很多的数据。
3.因为页的分裂,页会变得稀疏并且不规则的填充。因此最终数据是碎片的。
在读取许多随机值到聚簇索引中之后,你应该使用OPTIMIZE TABLE语句重新构建表并且优化的填充页。
这个例子告诉我们在使用InnoDB的时候要尽可能的顺序的插入数据,并且使用增长的聚簇索引。
更多精彩
赞助商链接