MYSQL网站制作之ORA FAQ 功能调剂系列之――紧缩索引会...

MySQL数据库归MySQLAB公司所有，但是这个软件是开源的，有一个MySQL学习教程可以免费下载。稍俱常识的新入门者都可以轻松实现在一个常见硬件上安装和配置MySQL。索引|功能|紧缩
Willcompressingmyindexesimproveperformance?
紧缩索引会进步功能么？

Authorsname:JonathanLewis

AuthorsEmail:Jonathan@jlcomp.demon.co.uk
Datewritten:26thFeb2003

Oracleversion(s):8.1-9.2

Compressedindexeshavebeenaroundforacoupleofyearsnow-butwillcompressingyourindexesautomaticallyimproveperformance?
紧缩索引已存在好几年了——那末紧缩索引会主动进步功能么？

OracleintroducedacompressionoptionforindexesinOracle8.1.Youcancreateanindexascompressed,orrebuildittocompressit(althoughtherearesomerestrictionsaboutonlinerebuilds,rebuildsofpartitionedindexesetc.)Typicalsyntaxmightbe:
Oracle在Oracle8.1中引进了索引的紧缩特征。你能够创立一个紧缩索引，大概重修时紧缩一个索引（只管对在线重修、重修分区索引等有一些限定）。尺度语法以下：

createindext1_ci_1ont1(col1,col2,col3,col4)compress2;

alterindext1_ci_1rebuildcompress2;

Thebenefitsofcompressioncomefromthefactthataproperlycompressedindexusesasmallernumberofleafblocks-whichtendstomeanthatlessI/Oisinvolvedwhentheindexisused,thereisareducedamountofbuffercacheflushing,andtheoptimizerislikelytocalculatealowercostforusingthatindexforrangescans.(Thereisatinychancethatthenumberofbranchblocks,andtheindexheightmightbereduced,too,butthatisalittleunlikely).
紧缩的上风来自一个得当紧缩的索引利用更少的叶块——如许当用到索引时触及更少的I/O，buffercache洗濯量减小，优化器对indexrangescan价值的盘算大概更低。（乃至无机会分支块数与索引高度也会削减，但这不太大概）。

Butcompressingindexes,especiallycompressingthewrongnumberofcolumns,canhavenegativeimpactonyourperformance.Ifyoucompressmorecolumnsthanyoushould,thecompressedindexmaybelargerthantheuncompressedindex.Usethevalidateoptionontheindex,andcheckviewindex_statstofindouttheoptimumcompressioncount.HowdidIknowthatIshouldcompressjustthefirsttwocolumnsofthet1_ci_1index?(Apartfromknowingthedata,thatis):
但紧缩索引，出格是紧缩烈数不准确时，会对功能发生负面影响。假如紧缩了过量的列，“紧缩”了的索引大概比未紧缩的索引更年夜。对索引利用validate选项，然后反省视图index_stats找到最优的紧缩数。我怎样晓得只必要紧缩索引t1_ci_1的前两列？（不必要晓得数据）：

validateindext1_ci_1;

select
opt_cmpt_count,opt_cmpr_pctsave
from
index_stats;

opt_cmpt_countopt_cmpr_pctsave
-------------------------------
250

Unfortunatelythesetwocolumnsdontexistin8.1,onlyinversion9(possiblyonly9.2).FortunatelySteveAdamshasascriptonhiswebsitetorecommendacompressionlevel(seewww.ixora.com.au)
不幸的是这两列在8.1中不存在，只存在于9（大概仅仅9.2）。侥幸的是SteveAdams在他的站点上有一个剧本以保举紧缩度（参考www.ixora.com.au）

Evenifyougettherightnumberofcolumnscompressed,thereisapricetopay:Themainpenaltiesare:(a)readsandmodsofacompressedindexcostmoreCPUthantheywould(typically)foranequivalentuncompressedindex(b)executionpathschange-andyoumaynothavepredictedthechanges,andsomenominallycheaperpathsmayactuallybeslower.forexample:Oraclemaychooseanindexfastfullscaninsteadofanindexrangescanbecausethecompressedindexisnowmuchsmaller,andyoursettingforparameterdb_file_multiblock_read_countislarge;orOraclemaychoosetouseanindexanddoanestedloopbecausetheindexisnow30%smaller,wherepreviouslyitwasdoingatablescanandhashjoin.
即便你失掉了紧缩列的“准确”数字，另有一个价值：次要的功能丧失是：(a)读、改一个紧缩索引比一个一律的未紧缩索引损耗更多的CPU；(b)实行路径改动——而且你大概没无意识到这个改动，一些看似价值更低的路径大概反而慢。比方：因为紧缩索引如今更小了，对参数db_file_multiblock_read_count也较年夜，那末Oracle大概选择一个indexfastfullscan而不是indexrangescan；大概因为索引减小了30%，Oracle选择利用一个索引和nestedloop，而之前它用表扫描和hashjoin。

So-dontgoandcompressalltheindexesinyourschema.
以是——不要紧缩一切索引。

Thinkcarefullyaboutwhichindexescouldgiveyousignificantgains,andwhetheryoucanaffordsomeCPUlosstoreducebufferthrashingandI/O.
想好谁人索引会给你较年夜的功能进步，你是不是可以接受一些CPU消耗来下降buffer洗濯和I/O。

Remembertoo,ifthewayyouuseanindexissuchthatthecolumnorderdoesntmatter,thenperhapsyoucouldrearrangethecolumnordertomaximisethecompression.Themostcriticalpoint,perhaps,isthatyoushouldavoidmovingacolumnthatistypicallyusedwitharangescantowardsthefrontoftheindex.t
还要记着，若你利用索引时其实不在乎列的按次，那末大概你能够从头布置列的按次来进步紧缩率。最关头的一点大概是你应该制止向索引前移一个一样平常用来rangescan的列。

--------------------------------------------------------------------------------
本文翻译自http://www.jlcomp.demon.co.uk/faq/译者仅保存翻译版权
据我的观察，现在有一个趋势，那些经过正式培训的数据库管理员DBA更倾向于选择一个专有关系数据库，例如Oracle。对于一些具有专门数据库管理员的比较大的环境来说，MySQL很难得到宠爱，这时候，关于MySQL是否真的具有良好的可扩展性的争论已经没有意义。