仓酷云

 找回密码
 立即注册
搜索
热搜: 活动 交友 discuz
查看: 1072|回复: 7
打印 上一主题 下一主题

[学习教程] MYSQL网页编程之利用MYSQL索引

[复制链接]
飘灵儿 该用户已被删除
跳转到指定楼层
楼主
发表于 2015-1-16 22:23:18 | 只看该作者 回帖奖励 |倒序浏览 |阅读模式

马上注册,结交更多好友,享用更多功能,让你轻松玩转社区。

您需要 登录 才可以下载或查看,没有帐号?立即注册

x
客户还是可以使用DBaaS系统所能提供的所有能力。数据库云服务消除了组织对专职人员、本地数据库存储设备的需要。他们不必安装、配置和维护任何软硬件。
干系数据库的天下是一个表与汇合、表与汇合上的运算占统治位置的天下。数据库是一个表的汇合,而表又是行和列的汇合。在公布一条SELECT查询从表中举行检索行时,失掉另外一个行和列的汇合。这些都是一些笼统的观点,关于数据库体系用来利用表中数据的基础
暗示没有几参考代价。另外一个笼统观点是,表上的运算都同时举行;查询是一种观点性的汇合运算,而且汇合论中没偶然间观点。固然,实际天下是相称分歧的。数据库办理体系完成了笼统的观点,可是在实践的硬件
局限内要遭到实践的物理束缚。结牵檠ㄊ奔洌惺币ê艹さ氖奔洹6逝世嗪苋菀撞荒头常幌不兜却虼宋颐嵌铝思仙系哪切┧布涞氖г怂愕某橄笫澜缛パ扒蠹铀俨檠姆椒āP以说氖牵屑钢旨铀僭怂愕募际酰啥员斫兴饕故菘夥衿鞑檎倚懈臁?煽悸窃跹浞掷谜庑┧饕幢嘈床檠?杀嘈从跋旆衿鞯鞫然频牟檠估醋远喔隹突Щ牟檠鞯酶谩N颐撬伎蓟居布跹诵校员阆氤鲈跹朔湮锢碓际孕阅芙懈纳频姆椒ā?br>这些恰是本章所要会商的成绩,其方针是优化数据库体系的功能,使其尽量快地处置各类查询。MySQL已相称快了,但即便是最快的数据库,在人的计划下还能运转得更快。
4.1利用索引
我们起首会商索引,由于它是加速查询的最主要的工具。另有其他加速查询的手艺,可是最无效的莫过于得当地利用索引了。在MySQL的邮件清单上,人们一般扣问关于使查询更快的成绩。在大批的案例中,都是由于表上没有索引,一样平常只需加上索引就能够当即办理成绩。但如许也并不是老是无效,由于优化并不是老是那样复杂。但是,假如不利用索引,在很多情况下,用其他手腕改良功能只会是华侈工夫。应当起首思索利用索引获得最年夜的功能改良,然后再追求其他大概有匡助的手艺。
本节先容索引是甚么、它如何改良查询功能、索引在甚么情形下大概会下降功能,和如何为表选择索引。下一节,我们将会商MySQL的查询优化程序。除晓得如何创立索引外,懂得一些优化程序的常识也是有优点的,由于如许能够更好天时用所创立的索引。某些编写查询的办法实践上会妨害索引的效果,应当制止这类情形呈现。(固然并不是总会如许。偶然也会但愿疏忽优化程序的感化。我们也将先容这些情形。)
4.1.1索引的好处
让我们从一个无索引的表动手来考查索引是如何起感化的。无索引的表就是一个无序的行集。比方,-1给出了我们在第1章“MySQL与SQL先容”中起首看到的ad表。这个表上没有索引,因而假如我们查找某个特定公司的行时,必需检察表中的每行,看它是不是与所需的值婚配。这是一个全表扫描,很慢,假如表中只要多数几个纪录与搜刮前提相婚配,则其效力是相称低的。
[img=283style=,290src=]http://www.ckuyun.com/[/img]
-2给出了不异的表,但在表的company_num列上增添了一个索引。此索引包括表中每行的一项,但此索引是在company_num上排序的。如今,不必要逐行搜刮全表查找婚配的条目,而是能够使用索引举行查找。假设我们要查找公司13的一切行,那末能够扫描索引,了局得出3行。然后抵达公司14的行,这是一个比我们正在查找的要年夜的号码。索引值是排序的,因而在读到包括14的纪录时,我们晓得不会再有婚配的纪录,能够加入了。假如查找一个值,它在索引表中某其中间点之前不会呈现,那末也有找到其第一个婚配索引项的定位算法,而不必举行表的按次扫描(如二分查找法)。如许,能够疾速定位到第一个婚配的值,以节俭大批搜刮工夫。数据库使用了林林总总的疾速定位索引值的手艺,这些手艺是甚么其实不主要,主要的是它们事情一般,索引手艺是个好器材。
有人会问,为何不但对数据文件举行排序,免却索引文件?如许不也在搜刮时发生不异的效果吗?问得好,假如只要单个索引时,
是如许的。不外有大概会用到第二个索引,但同时以两种分歧的办法对统一个数据文件举行排序是不成能的。(如,想要一个主顾名的索
引,同时又要一个主顾ID号或德律风号码的索引。)将索引文件作为一个与数据文件自力的实体就办理了这个成绩,并且同意创立多个索
引。别的,索引中的行一样平常要比数据文件中的行短。在拔出或删除值时,为坚持排序按次而挪动较短的索引值与挪动较长的数据行比拟更
为简单。
[img=472style=,288src=]http://www.ckuyun.com/[/img]
这个例子与MySQL索引表的办法符合。表的数据行保留在数据文件中,而索引值保留在索引文件中。一个表上可有不止一个索引;假如的确有不止一个索引,它们都保留在统一个索引文件中。索引文件中的每一个索引由排过序的用来疾速会见数据文件的键纪录数组组成。
后面的会商形貌了单表查询中索引的优点,个中利用索引打消了全表扫描,极年夜地加速了搜刮的速率。在实行触及多个表的毗连查询时,索引乃至会更有代价。在单个表的查询中,每列必要检察的值的数量就是表中行的数量。而在多个表的查询中,大概的组合数量极年夜,由于这个数量为各表中行数之积。
 假设有三个未索引的表t1、t2、t3,分离只包括列c1、c2、c3,每一个表分离由含无数值1到1000的1000行构成。查找对应值相称的表行组合的查询以下所示:
SELECTc1,c2,c3
FROMt1,t2,t3
WHEREc1=c2ANDc1=c3
此查询的了局应当为1000行,每一个组合包括3个相称的值。假如我们在无索引的情形下处置此查询,则不成能晓得哪些行包括那些值。因而,必需寻觅出一切组合以便得出与WHERE子句相配的那些组合。大概的组合数量为1000×1000×1000(十亿),比婚配数量多一百万倍。良多事情都华侈了,而且这个查询将会十分慢,即便在如像MySQL如许快的数据库中实行也会很慢。而这仍是每一个表中只要1000行的情况。假如每一个表中有一百万行时,将会如何?很明显,如许将会发生功能极其低下的了局。假如对每一个表举行索引,就可以极年夜地减速查询历程,由于使用索引的查询处置以下:
1)以下从表t1当选择第一行,检察此行所包括的值。
2)利用表t2上的索引,间接跳到t2中与来自t1的值婚配的行。相似,使用表t3上的索引,间接跳到t3中与来自t1的值婚配的行。
3)进到表t1的下一行偏重复后面的历程直到t1中一切的行已查过。在此情况下,我们仍旧对表t1实行了一个完整扫描,但可以在表t2和t3长进行索引查找间接掏出这些表中的行。从事理上说,这时候的查询比未用索引时要快一百万倍。如上所述,MySQL使用索引减速了WHERE子句中与前提相配的行的搜刮,大概说在实行毗连时加速了与其他表中的行婚配的行的搜刮。它也使用索引来改善其他操纵的功能:
■在利用MIN()和MAX()函数时,可以疾速找到索引列的最小或最年夜值。
■MySQL经常可以使用索引来完成ORDERBY子句的排序操纵。
■偶然,MySQL可制止对全部数据文件的读取。假设从一个索引数值列当选择值,并且不选择表中其他列。这时候,经由过程对索引值的读取,就已失掉了读取数据文件所要失掉的值。没有对不异的值举行两次读取的需要,因而,乃至无需触及数据文件。
4.1.2索引的坏处
一样平常情形下,假如MySQL可以晓得如何用索引来更快地处置查询,它就会如许做。这暗示,在年夜多半情形下,假如您不合错误表举行索引,则伤害的是您本人的好处。能够看出,作者刻画了索引的诸多优点。但有倒霉的地方吗?是的,有。实践上,这些弱点被长处所掩饰了,
但应当对它们有所懂得。
起首,索引文件要占磁盘空间。假如有大批的索引,索引文件大概会比数据文件更快地到达最年夜的文件尺寸。其次,索引文件加速了检索,但增添了拔出和删除,和更新索引列中的值的工夫(即,下降了年夜多半触及写进的操纵的工夫),由于写操纵不但触及数据行,并且还经常触及索引。一个表具有的索引越多,则写操纵的均匀功能下落就越年夜。在4.4节“无效地装载数据”中,我们将更加具体地先容这些功能成绩,并会商如何办理。
4.1.3选择索引
创立索引的语法已在3.4.3节“创立和删除索引”中举行了先容。这里,我们假定您已浏览过该节。可是晓得语法其实不能匡助断定表如何举行索引。要决意表如何举行索引必要思索表的利用体例。本节先容一些关于如何断定和选择索引列的原则:
■搜刮的索引列,纷歧定是所要选择的列。换句话说,最合适索引的列是呈现在WHERE子句中的列,或毗连子句中指定的列,而不是呈现在SELECT关头字后的选择列表中的列:

[img=373style=,158src=]http://www.ckuyun.com/[/img]
固然,所选择的列和用于WHERE子句的列也多是不异的。关头是,列呈现在选择列表中不是该列应当索引的标记。呈现在毗连子句中的列或呈现在形如col1=col2的表达式中的列是很合适索引的列。查询中的col_b和col_c就是如许的例子。假如MySQL能使用毗连列来优化一个查询,暗示它经由过程打消全表扫描相称可不雅地削减了表行的组合。
■利用唯一索引。思索某列中值的散布。关于唯一值的列,索引的效果最好,而具有多个反复值的列,其索引效果最差。比方,寄存岁数的列具有分歧值,很简单辨别各行。而用来纪录性其余列,只含有“M”和“F”,则对此列举行索引没有多年夜用途(不论搜刮哪一个值,城市得出约莫一半的行)。
■利用短索引。假如对串列举行索引,应当指定一个前缀长度,只需有大概就应当如许做。比方,假如有一个CHAR(200)列,假如在前10个或20个字符内,多半值是唯一的,那末就不要对全部列举行索引。对前10个或20个字符举行索引可以节俭大批索引空间,也大概会使查询更快。较小的索引触及的磁盘I/O较少,较短的值对照起来更快。更加主要的是,关于较短的键值,索引高速缓存中的块能包容更多的键值,因而,MySQL也能够在内存中包容更多的值。这增添了找到行而不必读取索引中较多块的大概性。(固然,应当使用一些知识。如仅用列值的第一个字符举行索引是不成能有多年夜优点的,由于这个索引中不会有很多分歧的值。)
■使用最左前缀。在创立一个n列的索引时,实践是创立了MySQL可使用的n个索引。多列索引可起几个索引的感化,由于可使用索引中最右边的列集来婚配行。如许的列集称为最左前缀。(这与索引一个列的前缀分歧,索引一个列的前缀是使用该的前n个字符作为索引值。)
假设一个表在分离名为state、city和zip的三个列上有一个索引。索引中的行是按state/city/zip的序次寄存的,因而,索引中的行也会主动按state/city的按次和state的按次寄存。这暗示,即便在查询中只指定state值或只指定state和city的值,MySQL也能够使用索引。因而,此索引可用来搜刮以下的列组合:
state,city,zip
state,city
sate
MySQL不克不及利用不触及左前缀的搜刮。比方,假如按city或zip举行搜刮,则不克不及利用该索引。假如要搜刮某个州和某个zip代码(索引中的列1和列3),则此索引不克不及用于响应值的组合。可是,可使用索引来寻觅与该州符合的行,以削减搜刮局限。
■不要过分索引。不要觉得索引“越多越好”,甚么器材都用索引是错的。每一个分外的索引都要占用分外的磁盘空间,并下降写操纵的功能,这一点我们后面已先容过。在修正表的内容时,索引必需举行更新,偶然大概必要重构,因而,索引越多,所花的工夫越长。假如有一个索引很少使用或从不利用,那末会不用要地减缓表的修正速率。别的,MySQL在天生一个实行企图时,要思索各个索引,这也要费工夫。创立过剩的索引给查询优化带来了更多的事情。索引太多,也大概会使MySQL选择不到所要利用的最好索引。只坚持所需的索引有益于查询优化。假如想给已索引的表增添索引,应当思索所要增添的索引是不是是现有多列索引的最左索引。假如是,则就不要吃力往增添这个索引了,由于已有了。
■思索在列长进行的对照范例。索引可用于“<”、“<=”、“=”、“>=”、“>”和BETWEEN运算。在形式具有一个间接量前缀时,索引也用于LIKE运算。假如只将某个列用于其他范例的运算时(如STRCMP()),对其举行索引没有代价。


一些典型的RDBMS功能并不总是在DBaaS系统中可用。例如MySQL学习教程,WindowsAzureSQLDatabase(以前的SQLAzure)是微软的DBaaS产品,提供了一个类似于SQLServer的数据库平台。
蒙在股里 该用户已被删除
沙发
发表于 2015-1-19 10:08:57 | 只看该作者
多走走一此相关论坛,多看一些实例开发,多交流0经验,没什么的,我也是刚学没多久!加油
简单生活 该用户已被删除
板凳
发表于 2015-1-26 21:41:14 | 只看该作者
备份方面可能还是一个老大难的问题。不能单独备份几个表总是感觉不爽。灵活备份的问题不知道什么时候才能解决。
莫相离 该用户已被删除
地板
发表于 2015-2-4 21:20:19 | 只看该作者
如果你是从“学习某一种数据库应用软件,从而获得应聘的资本和工作机会”的角度来问的话。
柔情似水 该用户已被删除
5#
发表于 2015-2-10 13:15:40 | 只看该作者
不好!如果出了错;不好调试;不好处理!其实web开发将代码分为3层:web层;业务逻辑层和数据访问层;一般对数据库的操作都在数据访问层来做;这样便于调试和维护!而且将来如果是换了数据库的话;你只需要改数据层的代码;其他层的基本可以不变!要是你在jsp中直接调用sql数据库;那么如果换了数据库呢?岂不都要改?如果报了异常呢?怎么做异常处理?
小女巫 该用户已被删除
6#
发表于 2015-3-1 11:09:09 | 只看该作者
连做梦都在想页面结构是怎么样的,绝非虚言
7#
发表于 2015-3-17 09:09:27 | 只看该作者
只能告诉你,学好数据库语言和原理,多见识几种数据库软件,比一棵树上吊死要好。
再现理想 该用户已被删除
8#
发表于 2015-3-24 05:13:40 | 只看该作者
发几份SQL课件,以飨阅者
您需要登录后才可以回帖 登录 | 立即注册

本版积分规则

QQ|Archiver|手机版|仓酷云 鄂ICP备14007578号-2

GMT+8, 2024-5-17 12:55

Powered by Discuz! X3.2

© 2001-2013 Comsenz Inc.

快速回复 返回顶部 返回列表