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是否真的具有良好的可扩展性的争论已经没有意义。 如安全管理、备份恢复、性能监控和调优等，SQL只要熟悉基本操作就可以，只要程序设计部分只要稍加了解即可（如存储过程、触发器等）。 作了些试验，发现使用CLR的存储过程或函数在达到一定的阀值的时候，系统性能会呈指数级下滑！这是非常危险的！只使用几个可能没有问题，当一旦大规模使用会造成严重的系统性能问题！ 以前的DTS轻盈简单。但是现在的SSIS虽然功能强大了很多，但是总是让人感觉太麻烦。看看论坛中询问SSIS的贴子就知道。做的功能太强大了，往往会有很多用户不会用了 记得在最开始使用2k的时候就要用到这个功能，可惜2k没有，现在有了作解决方案的朋友会很高兴吧。 现在是在考虑:如果写到服务器端,我一下搞他个10个存储过程导过去,那久之服务器不就成垃圾箱了吗?即便优化了我的中间层. 所以你总能得到相应的升级版本，来满足你的需求。
页:
[1]