這裡蒐索程式師資訊,查找有用的技術資料
当前位置:首页 » 数据仓库 » 诊断测试索引数据库
扩展阅读
webinf下怎么引入js 2023-08-31 21:54:13
堡垒机怎么打开web 2023-08-31 21:54:11

诊断测试索引数据库

发布时间: 2023-06-11 02:19:25

A. 中国生物医学文献数据库 cbm 的检索途径有哪些

您好,很高兴为您解答。

一.检索途径和方法
CBMdisc数据库中使用的布尔逻辑运算符一般有“AND”、“OR”、“AND NOT”,
通配符:“?”,可替代任何一中文字符,例如:张?、张伟?。
范围运算符:仅用于出版年字段的检索,对检索结果进行时间限定。
=(等于) 例PY = 2001 检索2001年发表的文献;
>(大于) 例PY > 1998 检索1998年以后发表的文献;
<(小于) 例PY < 1997 检索1997年以前发表的文献;
>=(大于等于) 例PY >= 1992 检索1992年以来(包括1992年)发表的文献;
<=(小于等于) 例PY <= 1990 检索1990年以前(包括1990年)发表的文献。
CBMDisc提供了5种检索途径,即基本检索、主题词检索、索引词检索、分类检索和期刊检索。
1.基本检索
可直接在检索框内输入有效检索词进行单字、文本词的检索,只要文献记录中出现与
检索词相同的实义词,系统一律检出。
⑴ 在基本检索状态下,可进行以下一些辅助检索:
① 缺省字段:系统默认字段,表示在中文题目、文摘、作者、主题词、特征词、关键词、期刊字段查找用户输入的检索词。
②全部字段:表示在所有可检索的字符型字段中查找用户输入的检索词。这种检索方式可使检索结果较全。
③特定字段:指仅在某一指定字段内检索用户输入的检索词,如中文标题、英文标题、作者、地址、期刊等。特定字段检索需在检索词前后加字段标识符,“标识符”表示精确检索,“in 标识符”,表示对所选字段的任意片段进行查找。
例:“au =李平”,为精确检索,检出的结果均为作者“李平”发表的文章; “李平 in au”,为非精确检索,在作者字段中有“李平”或“李平贵”的文献均被检出;
④引文字段:通过“参考文献”字段可了解某种文献被引用情况。
例:查找“吴孟超”发表论文或着作被引用的情况,方法是:在“缺省“下拉菜单中选择“参考文献”字段,输入“吴孟超”,点击“检索”即可显示作者文献的被引用结果。再点击“显示”按钮进入引文题录界面。
⑵ 各按钮作用及使用方法
①“显示”按钮 显示光标指向的检索式的检索结果。
②“删除”按钮 删除无用的检索式。
③“选中”按钮 用鼠标单检索式,然后点击“选中”按钮,该检索式呈浅蓝色。然后选择“AND”、“OR ”、“NOT”按钮进行逻辑运算。如果想取消选中状态,再点击“清除”按钮,此时,检索式浅蓝色标记消失。
例:肝炎治疗
首先在检索框内分别输入肝炎和治疗,在检索结果式列表中,点击肝炎检索表达式,然后点击“选中”按钮,接着点击治疗检索表达式,再点击“选中”按钮,被点击后的两个检索表达式均呈浅蓝色,最后点击“AND”按钮将二者组配,即可得到肝炎治疗的文献。
④“二次检索”按钮 可在第一次检索结果的基础上进行二次检索,或重新检索。检索方法与一次检索相同。在二次检索屏幕,系统显示一次检索所使用的数据库、字段、检索式,以及一次检索的命中篇数。可在一次检索的基础上进行限制检索,可浏览检出文献题目。
提示注意:“加入列表”和“检索列表”一般用于检索结果中的任何字段内容(如标题、文摘、关键词等)。使用方法:即在检索结果显示文献中,用鼠标选中被检索词(呈浅绿色),然后点击“加入列表”按钮,接着点击“检索列表”,此时被检索词自动添加到检索列表式中,进行限定检索。
⑶ 关键词检索适用范围:
①不太熟悉规范的主题词时,可先输入关键词,再在显示记录的主题词字段中找到相应的主题词,进行更系统,更全面的检索。
②没有相应的主题词,包括:A. 新出现的科技术语,新发现的物质及疾病名称:
B. 某些特写概念,如体重、海拔、高度、剂量等:C. 中医药名称;
③在使用主题词不能检出满意的文献时,采用自由词,可能会扩大检索结果,并可根据记录中显示的主题词,比较使用的主题词是否合适或重新确定主题词。
2.主题词检索
CBMDisc主题词表收录了美国国立医学图书馆《医学主题词表》(即MESH)和中国中医研究院出版的《中医药学主题词表》的所有词条。医学主题词表是对生物医学文献进行主题分析、标引和检索时使用的权威性词表,它的作用是使医学文献的主题标引达到统一和一致,并指导用户高质量地检索医学文献。
在基本检索页面点击“主题词”按钮进入主题词检索页。可选择中文主题词或英文主题词两种查找方式,在输入框键入主题词后点击“浏览”按钮进入主题词树形结构页,可根据系统显示的同义词、相关词、上位词或下位词进行检索,选择主题词后可对该词进行扩展检索、加权检索及主题词与副主题词组配检索。
例1: 阿司匹林诱发哮喘
本课题包含两个主题概念,即阿司匹林和哮喘,按照MESH标引规则, 应查同时包含“阿司匹林/副作用”与“哮喘/化学诱导”两方面内容的文献。步骤如下:
⑴ 在“中文主题词” 对话框下输入 “阿司匹林”,点击“浏览”按钮,再点击“主题词注释”进入阿司匹林的英文名称和树形结构页;在检索选项中选择“扩展”或“不扩展”;再点击“检索”;这时出现副主题词对话框,根据课题要求,用户可选择相匹配的副主题词。本检索选择“副作用”,点击“确认”按钮。
⑵ 采取以上方法,在“哮喘”主题词下, 选择“化学诱导”副主题词。
⑶ 将以上两个检索结果分别“选中”,点击“AND”则显示最终检索结果。
例2:肺癌的诊断
“肺癌”这个词不是规范的主题词,因此输入之后,轮排词表中没有显示,只有“小细胞肺癌”,这个范畴显然太小了,要转换成相应的主题词“肺肿瘤”之后,再进行检索。在出现肺肿瘤树状结构状态下,进行扩展检索,选择全部的扩展树,可将“肺肿瘤”的全部下位类如支气管肿瘤、支气管原癌、PANCOAST综合征等内容的全部文献进行扩展检索,再与副主题词“诊断”组配。可选择“E英文检索主题词”,输入Lung neoplasms,在英汉对照主题词轮排表中,按字顺找到Lung Neoplasms=肺肿瘤,点击“检索”,选择“诊断”或“超声诊断”等相关副主题词后确定,即得检索结果。
CBMDisc主题词表与MESH词表完全对应,因此当读者不知某个主题词的英文拼写时,可通过CBMDisc主题词表的主题词注释,找到其正确的英文主题词,进而检索英文数据库。还可通过显示文献的英文题目(TT),找到对应于某个中文词的英文表达方式。
从理论上讲,主题词检索有助于提高文献的查全率和查准率,应是最理想的检索途径,但CBMDisc在标引深度、标引的准确性、一致性等方面,都不及MEDLINE,其主题词检索效果往往不及自由词检索来得全。
3.索引词检索
索引词表收录了数据库中所有可检索字段中的所有单个字和部分词组, 以及主题词、汇编名称等,该表有助于用户通过浏览方式选词检索。
检索方法:点击“索引”按钮,在提问框中输入检索词,点击“浏览”按钮或按回车键,系统显示索引词表;包括索引词,命中记录数和索引词的出现数;点中一个索引词(呈浅蓝色),然后点击“检索”按钮。索引词表检索仅在默认字段进行,即:题目、文摘、关键词、主题词和刊名字段。表中列出的命中文献数为所有字段的检索结果。
4.分类检索
点击“分类”按钮,系统进入分类检索状态。分类表包括《中国图书资料分类法》第三版R类的内容,其排列规则为:总论复分表排在最前面,标记符号为“-”,其次是临床专用复分表,标记符号为“0”,即01-09,分别表示预防控制、病理学、医学免疫学、诊断学、治疗学等复分类目;最后是主类号,即R1、R2、R3、R4、R5、R6、R7、R8、R9的全部类目。可以通过“分类号”和“分类词”进行检索或选用复分号进行扩展检索。
5.期刊检索
点击“期刊”按钮,系统进入期刊检索状态。期刊检索可从刊名、出版地、出版单位以及主题词途径等进行检索。
方法:在期刊检索输入框输入刊名等检索词,点击右侧的“浏览”按钮,屏幕显示有关期刊列表,即有关的刊名和出版单位;欲浏览期刊信息,方法1:可直接点击刊名,进入期刊显示屏幕。该屏详细显示期刊全部信息,如国际期刊代码、国内期刊代码、期刊内部代码、邮发代码、创刊年、主办单位地址、邮编、电话、期刊变更注释、以及主题词、分类号等内容。方法2:点击“词条注释”按钮,显示该期刊主编、编辑单位、编辑部电话、地址、邮编、刊号等内容,可作为投稿信息。
6.主题词与副主题词组配检索
主题词与相应的副主题词进行组配检索。副主题词包括MESH词表中的82个副主题词和中医药主题词表中的10多个中医药方面的副主题词。
7.其它组配检索
在实际检索过程中,可根据课题需要进行各种组配检索。如主题词与自由词组配检索,主题词和着者组配检索,关键词和期刊组配检索,着者和期刊组配检索等等。下面举例说明主题词和自由词检索。
例:急性心肌梗塞的治疗
分析:“心肌梗塞”有相应的主题词, 属于治疗方面的副主题词有:饮食疗法,药物疗法, 外科学, 放射疗法,中医药疗法, 按摩疗法, 穴位疗法, 针灸疗法,中西医结合疗法, 气功疗法等可与之组配, 但没有“急性心肌梗塞”这个主题词, 因此用自由词“急性”来限定。
检索步骤:
⑴ 在“主题词”状态下输入“心肌梗塞”(Myocardial Infarction),点击“浏览”按钮或按回车键,双击被检索词,扩展检索,然后点击“检索”按钮,进入选择副主题词界面,用户可根据需要用鼠标选中左边副主题词框的副主题词(呈浅蓝色),或按下Ctrl键选择多项副主题词,点击“添加”按钮,把选中的副主题词添加到右边的选中副主题框里,再点击“确认”按钮,可将选择的副主题词(框)与之组配限定;
⑵ 在“检索”状态下输入关键词“急性”,点击“检索”按钮;
⑶ 再将以上两个检索结果表达式分别“选中”,点击“AND”按钮将二者组配,即可得到最后的检索结果。
二.检索结果显示、标记、套录
⑴ 显示 用鼠标双击检索表达式或单击“显示”按钮,即可显示该检索结果文献的题录,文献浏览格式有题录和文摘格式选择,一般系统默认题录格式,只要点击“题录格式”按钮便切换到文摘格式。
⑵ 标记 在浏览状态下可对相关文献进行标记,标记时只需用鼠标点击选中文献左上角书本图标,该条记录左边即显示一列红色星号,再点击红色星号便取消标记。标记后点击“显标注”按钮,即可对标记记录和全部记录进行选择浏览。
⑶ 套录 选中标记后,点击“套录”按钮,弹出套录窗口,点击“套录参数”按钮逐项选择“确认”后,进行选择相应文本框内输入存盘路径、文件名及存盘的文献类型等,即把命中文献存盘。点击“追加”按钮,可将多次检索标记的文献存入同一文件名下。
⑷ 打印 在选中标记后,点击“打印”按钮,弹出打印窗口,点击“打印参数”按钮逐项选择“确认”后,最后按“打印”按钮即可进行打印。
数据库检索完毕后,直接点击页面右上角“╳”符号即可。

如若满意,请点击右侧【采纳答案】,如若还有问题,请点击【追问】

希望我的回答对您有所帮助,望采纳!

~ O(∩_∩)O~

B. 软件开发数据库如何进行测试

比如:数据冗余,功能和性能方面存在的问题已经严重影响应用软件的使用。软件测试人员往往重视对软件功能和编码的测试,而忽略对软件性能,特别是数据库访问并发测试。因为,他们固有的思想中认为数据库设计存在问题对系统性能影响不大,或从根本上忽略了数据库在软件开发中的地位,直到出现了问题,才想到对数据库的测试,但往往也是仅仅通过对编码的测试工作中捎带对数据库进行一定的测试,这远远是不够的。目前,中铁网上订票系统在大用户同时在线订票中系统频频瘫痪,就是最好的佐证。 所以,在应用软件的测试工作中,应该将数据库作为一个独立的部分进行充分的测试,这样才可以得到应用软件所需要的性能优化的数据库。那么,应该对哪些内容进行测试,如何进行测试呢? 2、数据库设计的测试 数据库是应用的基础,其性能直接影响应用软件的性能。为了使数据库具有较好的性能,需要对数据库中的表进行规范化设计。规范化的范式可分为第一范式、第二范式、第三范式、BCNF范式、第四范式和第五范式。一般来说,逻辑数据库设计应满足第三范式的要求,这是因为满足第三范式的表结构容易维护,且基本满足实际应用的要求。因此,实际应用中一般都按照第三范式的标准进行规范化。但是,规范化也有缺点:由于将一个表拆分成为多个表,在查询时需要多表连接,降低了查询速度。故数据库设计的测试包括前期需求分析产生数据库逻辑模型和后期业务系统开发中的测试两部分(这里指的是后者),我在这里称为实体测试。 数据库是由若干的实体组成的,包括(表,视图,存储过程等),数据库最基本的测试就是实体测试,通过对这些实体的测试,可以发现数据库实体设计得是否充分,是否有遗漏,每个实体的内容是否全面,扩展性如何。 实体测试,可以用来发现应用软件在功能上存在的不足,也可以发现数据冗余的问题。经过测试,测试人员对有异议的问题要及时和数据库的设计人员进行沟通解决。 3、数据一致性测试 在进行实体测试后,应进一步检查下面的内容以保障数据的一致性: 3.1 表的主键测试根据应用系统的实际需求,对每个表的主键进行测试,验证是否存在记录不唯一的情况,如果有,则要重新设置主键,使表中记录唯一。 3.2 表之间主外键关系的测试数据库中主外键字段在名称,数据类型,字段长度上的一致性测试。 3.3 级联表,删除主表数据后,相应从报表数据应同时删除的问题例如学生表和学生成绩表,学生数据已经删除,成绩表中相应学生的成绩记录应同时删除。 3.4 存储过程和触发器的测试存储过程可以人工执行,但触发器不能人工处理,所以在对存储过程和触发器执行的过程中针对sql SERVER2005及以上版本可以使用Microsoft SQL Server Profiler性能测试工具进行测试。 Microsoft SQL Server Profiler 是 SQL 跟踪的图形用户界面,用于监视数据库引擎或 Analysis Services 的实例。测试人员可以捕获有关每个事件的数据并将其保存到文件或表中供以后分析。例如:可以对生产环境进行监视,了解哪些存储过程由于执行速度太慢影响了性能。 4、数据库的容量测试 随着数据库系统的使用,数据量在飞速增长,如何在使用前对数据容量的增长情况进行初步估算,为最终用户提供参考,这在数据库使用和维护过程中,是非常重要的。可以通过对数据库设计中基本表的数据大小,和每天数据表的数据产生量进行初步估算。 记录数据量=各个字段所占字节数的总和表的数据量=记录数据量*记录数数据库大小=各表数据量的总和 当然,数据库的大小不仅仅只是基本表的大小,还有系统表,视图,存储过程等其它实体所占的容量,但最基本的数据是表的数据。另外,数据库的容量还包括数据库日志文件的容量,一般应预留数据库文件的2倍左右。 5、数据库的性能测试 应用软件除了功能外,很重要的一部分就是软件的性能,而对于数据库系统,数据库性能的好坏会直接影响应用软件的性能,这部分的测试,一般手工测试就显得无能为力了,这时就要借助自动化的测试软件,例如:DataFactory,DataFactory是一种强大的数据产生器,它允许开发人员和测试人员很容易产生百万行有意义的正确的测试数据库,该工具支持DB2、Oracle、Sybase、SQL Server数据库。这样,就可以模拟出应用软件长期使用后,海量数据存储的数据库的性能状况。从而尽早发现问题,进行数据库性能的优化。 这里要注意,进行性能测试的时候,一定要注意测试环境的一致性,包括:操作系统、应用软件的版本以及硬件的配置等,而且在进行数据库方面的测试的时候一定要注意数据库的记录数、配置等要一致,只有在相同条件下进行测试,才可以对结果进行比较。否则无法和用户对软件的性能的观点达成一致。 6、数据库的压力测试 说起测试,我们首先想到的就是软件正确性的测试,即常说的功能测试。软件功能正确仅是软件质量合格指标之一。在实际开发中,还有其它的非功能因素也起着决定性的因素,例如软件的响应速度。影响软件响应速度的因素有很多,有些是因为算法不够高效;还有些可能受用户并发数的影响。 在众多类型的软件测试中,压力测试正是以软件响应速度为测试目标,尤其是针对在较短时间内大量并发用户的访问时,软件的抗压能力。但压力测试往往是手工难以测试的,必须借助自动化测试工具。常用的压力测试有:Web测试、数据库测试等。 数据库在大多数软件项目中是不可缺少的,对于它进行压力测试是为了找出数据库对象是否可以有效地承受来自多个用户的并发访问。这些对象主要是:索引、触发器、存储过程和锁。通过对SQL语句和存储过程的测试,自动化的压力测试工具可以间接的反应数据库对象是否需要优化。 这些自动化的测试工具很多,各有特点,基于Java的项目可以使用JMeter,.Net项目可以采用.Net集成开发环境中提供的测试方案。 7、结束语 总之,在应用系统的测试中,把数据库应当作为独立的系统来测试,这无疑会为应用软件的质量增加可靠的保障,同时还必须结合应用软件进行集成测试,只有二者有机结合起来,才能最大限度的发挥数据库和应用软件的功能。

C. 常用的医学数据库和网络医学资源有哪些

有MEDLINE、《中华医学杂志》、骨密度数据库、CBM、PubMed等。

1、MEDLINE

MEDLINE是美国国立医学图书馆(The National Library of Medicine, 简称NLM)生产的国际性综合生物医学信息书目数据库,是当前国际上最权威的生物医学文献数据库。

内容包括美国《医学索引》(Index Medicus, IM)的全部内容和《牙科文献索引》(Index to Dental Literature)、《国际护理索引》(International Nursing Index)的部分内容。

2、《中华医学杂志》

《中华医学杂志》是1915年创办的双语学术期刊,周刊,中国科学技术协会主管,中华医学会主办。

期刊主要反映中国医学最新的科研成果,积极推广医药卫生领域的新技术、新成果,及时交流防病治病的新经验。

3、骨密度数据库

2004 年11 月,GE 公司与中华医学会合作, 完成中国大陆骨密度正常值数据库项目,开创了中国骨密度发展的新时代,是中国医学界将临床问题数字化的一项巨大突破。

该项目的完成, 彻底结束了用其他人种的标准诊断中国人骨密度状况的混乱局面,树立了医生和患者对骨密度测量和骨质疏松定量诊断的信任。

4、CBM

CBM由中国医学科学院医学信息研究所/图书馆开发研制的中国生物医学文献服务系统(SinoMed);

整合了中国生物医学文献数据库(CBM)、西文生物医学文献数据库(WBM)、北京协和医学院博硕学位论文库等多种资源,是集检索、免费获取、个性化定题服务、全文传递服务于一体的生物医学中外文整合文献服务系统。

可访问中国生物医学文献数据库(CBM)资源 ,北京协和医学院博硕学位论文库(每篇论文的前30页内容)。

CBM收录1978以来1600余种中国生物医学期刊,以及汇编、会议论文的文献题录530余万篇,全部题录均进行主题标引和分类标引等规范化加工处理。年增文献40余万篇,每月更新。

5、PubMed

PubMed 数据库是美国国立医学图书馆(National libraryof Medicine, NLM) 的国家生物技术信息中心(National Center for Biotechnology Information,NCBI)研制开发的, 设在国家健康研究院。

PubMed 数据库收录MEDLINE, PRE-MEDLINE, 还有其它如《Science》, 《Nature》 等电子期刊构成的数据库。 自1996年至今,该数据库收录约1000 万篇生物医学文献。

可供检索的专业为,分子生物学及NCBI 部分的数据库题录。它收录了美国和另外70 个国家出版的生物医学期刊约3900种。

PubMed 网上更新速度是每周1次。Medline 收录的大多数论文原始语种是英语, 或有英文摘要。

参考资料来源:网络——医学数据库

D. 数据库索引的操作案例

最普通的情况,是为出现在where子句的字段建一个索引。为方便讲述,先建立一个如下的表。
CREATE TABLE mytable(
idserial primary key,
category_id int not null default0,
user_id int not null default0,
adddate int not null default0
);
如果在查询时常用类似以下的语句:
SELECT * FROM mytable WHERE category_id=1;
最直接的应对之道,是为category_id建立一个简单的索引:
CREATE INDEX mytable_categoryid ON mytable (category_id);
OK.如果有不止一个选择条件呢?例如:
SELECT * FROM mytable WHERE category_id=1 AND user_id=2;
第一反应可能是,再给user_id建立一个索引。不好,这不是一个最佳的方法。可以建立多重的索引。
CREATE INDEX mytable_categoryid_userid ON mytable(category_id,user_id);
注意到在命名时的习惯了吗?使用表名_字段1名_字段2名的方式。很快就会知道为什么这样做了。
现在已经为适当的字段建立了索引,不过,还是有点不放心吧,可能会问,数据库会真正用到这些索引吗?测试一下就OK,对于大多数的数据库来说,这是很容易的,只要使用EXPLAIN命令:
EXPLAIN
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2;
This is what Postgres 7.1 returns (exactlyasI expected)
NOTICE:QUERY PLAN:
Index Scan using mytable_categoryid_userid on
mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
以上是postgres的数据,可以看到该数据库在查询的时候使用了一个索引(一个好开始),而且它使用的是创建的第二个索引。看到上面命名的好处了吧,马上知道它使用适当的索引了。
接着,来个稍微复杂一点的,如果有个ORDERBY 子句呢?不管你信不信,大多数的数据库在使用orderby的时候,都将会从索引中受益。
SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
很简单,就像为where子句中的字段建立一个索引一样,也为ORDER BY的子句中的字段建立一个索引:
CREATE INDEX mytable_categoryid_userid_adddate ON mytable (category_id,user_id,adddate);
注意:mytable_categoryid_userid_adddate将会被截短为mytable_categoryid_userid_addda
CREATE
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY adddate DESC;
NOTICE:QUERY PLAN:
Sort(cost=2.03..2.03 rows=1 width=16)
->Index Scanusing mytable_categoryid_userid_addda
on mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
看看EXPLAIN的输出,数据库多做了一个没有要求的排序,这下知道性能如何受损了吧,看来对于数据库的自身运作是有点过于乐观了,那么,给数据库多一点提示吧。
为了跳过排序这一步,并不需要其它另外的索引,只要将查询语句稍微改一下。这里用的是postgres,将给该数据库一个额外的提示--在ORDER BY语句中,加入where语句中的字段。这只是一个技术上的处理,并不是必须的,因为实际上在另外两个字段上,并不会有任何的排序操作,不过如果加入,postgres将会知道哪些是它应该做的。
EXPLAIN SELECT * FROM mytable
WHERE category_id=1 AND user_id=2
ORDER BY category_id DESC,user_id DESC,adddate DESC;
NOTICE:QUERY PLAN:
Index Scan Backward using
mytable_categoryid_userid_addda on mytable(cost=0.00..2.02 rows=1 width=16)
EXPLAIN
现在使用料想的索引了,而且它还挺聪明,知道可以从索引后面开始读,从而避免了任何的排序。
以上说得细了一点,不过如果数据库非常巨大,并且每日的页面请求达上百万算,想会获益良多的。不过,如果要做更为复杂的查询呢,例如将多张表结合起来查询,特别是where限制字句中的字段是来自不止一个表格时,应该怎样处理呢?通常都尽量避免这种做法,因为这样数据库要将各个表中的东西都结合起来,然后再排除那些不合适的行,搞不好开销会很大。
如果不能避免,应该查看每张要结合起来的表,并且使用以上的策略来建立索引,然后再用EXPLAIN命令验证一下是否使用了料想中的索引。如果是的话,就OK。不是的话,可能要建立临时的表来将他们结合在一起,并且使用适当的索引。
要注意的是,建立太多的索引将会影响更新和插入的速度,因为它需要同样更新每个索引文件。对于一个经常需要更新和插入的表格,就没有必要为一个很少使用的where字句单独建立索引了,对于比较小的表,排序的开销不会很大,也没有必要建立另外的索引。
以上介绍的只是一些十分基本的东西,其实里面的学问也不少,单凭EXPLAIN是不能判定该方法是否就是最优化的,每个数据库都有自己的一些优化器,虽然可能还不太完善,但是它们都会在查询时对比过哪种方式较快,在某些情况下,建立索引的话也未必会快,例如索引放在一个不连续的存储空间时,这会增加读磁盘的负担,因此,哪个是最优,应该通过实际的使用环境来检验。
在刚开始的时候,如果表不大,没有必要作索引,意见是在需要的时候才作索引,也可用一些命令来优化表,例如MySQL可用OPTIMIZETABLE。

E. mysql数据库性能测试

我理解的是你希望了解mysql性能测试的方法:
其实常用的一般:
选取最适用的字段属性
MySQL可以很好的支持大数据量的存取,但是一般说来,数据库中的表越小,在它上面执行的查询也就会越快。因此,在创建表的时候,为了获得更好的性能,我们可以将表中字段的宽度设得尽可能小。例如,在定义邮政编码这个字段时,如果将其设置为CHAR(255),显然给数据库增加了不必要的空间,甚至使用VARCHAR这种类型也是多余的,因为CHAR(6)就可以很好的完成任务了。同样的,如果可以的话,我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。

另外一个提高效率的方法是在可能的情况下,应该尽量把字段设置为NOT NULL,这样在将来执行查询的时候,数据库不用去比较NULL值。

对于某些文本字段,例如“省份”或者“性别”,我们可以将它们定义为ENUM类型。因为在MySQL中,ENUM类型被当作数值型数据来处理,而数值型数据被处理起来的速度要比文本类型快得多。这样,我们又可以提高数据库的性能。

2、使用连接(JOIN)来代替子查询(Sub-Queries)

MySQL从4.1开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果,然后把这个结果作为过滤条件用在另一个查询中。例如,我们要将客户基本信息表中没有任何订单的客户删除掉,就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来,然后将结果传递给主查询,如下所示:

DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )

使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL操作,同时也可以避免事务或者表锁死,并且写起来也很容易。但是,有些情况下,子查询可以被更有效率的连接(JOIN).. 替代。例如,假设我们要将所有没有订单记录的用户取出来,可以用下面这个查询完成:

SELECT * FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )

如果使用连接(JOIN).. 来完成这个查询工作,速度将会快很多。尤其是当salesinfo表中对CustomerID建有索引的话,性能将会更好,查询如下:

SELECT * FROM customerinfo LEFT JOIN salesinfoON customerinfo.CustomerID=salesinfo. CustomerID WHERE salesinfo.CustomerID IS NULL

连接(JOIN).. 之所以更有效率一些,是因为 MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。

3、使用联合(UNION)来代替手动创建的临时表

MySQL 从 4.0 的版本开始支持 UNION 查询,它可以把需要使用临时表的两条或更多的 SELECT 查询合并的一个查询中。在客户端的查询会话结束的时候,临时表会被自动删除,从而保证数据库整齐、高效。使用 UNION 来创建查询的时候,我们只需要用 UNION作为关键字把多个 SELECT 语句连接起来就可以了,要注意的是所有 SELECT 语句中的字段数目要想同。下面的例子就演示了一个使用 UNION的查询。

SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM author
UNION
SELECT Name, Supplier FROM proct

4、事务

尽管我们可以使用子查询(Sub-Queries)、连接(JOIN)和联合(UNION)来创建各种各样的查询,但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情况下,当这个语句块中的某一条语句运行出错的时候,整个语句块的操作就会变得不确定起来。设想一下,要把某个数据同时插入两个相关联的表中,可能会出现这样的情况:第一个表中成功更新后,数据库突然出现意外状况,造成第二个表中的操作没有完成,这样,就会造成数据的不完整,甚至会破坏数据库中的数据。要避免这种情况,就应该使用事务,它的作用是:要么语句块中每条语句都操作成功,要么都失败。换句话说,就是可以保持数据库中数据的一致性和完整性。事物以BEGIN 关键字开始,COMMIT关键字结束。在这之间的一条SQL操作失败,那么,ROLLBACK命令就可以把数据库恢复到BEGIN开始之前的状态。

BEGIN;

INSERT INTO salesinfo SET CustomerID=14;

UPDATE inventory SET Quantity=11

WHERE item='book';

COMMIT;

事务的另一个重要作用是当多个用户同时使用相同的数据源时,它可以利用锁定数据库的方法来为用户提供一种安全的访问方式,这样可以保证用户的操作不被其它的用户所干扰。

5、锁定表

尽管事务是维护数据库完整性的一个非常好的方法,但却因为它的独占性,有时会影响数据库的性能,尤其是在很大的应用系统中。由于在事务执行的过程中,数据库将会被锁定,因此其它的用户请求只能暂时等待直到该事务结束。如果一个数据库系统只有少数几个用户

来使用,事务造成的影响不会成为一个太大的问题;但假设有成千上万的用户同时访问一个数据库系统,例如访问一个电子商务网站,就会产生比较严重的响应延迟。

其实,有些情况下我们可以通过锁定表的方法来获得更好的性能。下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。

LOCK TABLE inventory WRITE
SELECT Quantity FROM inventory
WHEREItem='book';
...

UPDATE inventory SET Quantity=11
WHEREItem='book';
UNLOCK TABLES

这里,我们用一个 SELECT 语句取出初始数据,通过一些计算,用 UPDATE 语句将新值更新到表中。包含有 WRITE 关键字的 LOCK TABLE 语句可以保证在 UNLOCK TABLES 命令被执行之前,不会有其它的访问来对 inventory 进行插入、更新或者删除的操作。

6、使用外键

锁定表的方法可以维护数据的完整性,但是它却不能保证数据的关联性。这个时候我们就可以使用外键。例如,外键可以保证每一条销售记录都指向某一个存在的客户。在这里,外键可以把customerinfo 表中的CustomerID映射到salesinfo表中CustomerID,任何一条没有合法CustomerID的记录都不会被更新或插入到salesinfo中。

CREATE TABLE customerinfo
(
CustomerID INT NOT NULL ,
PRIMARY KEY ( CustomerID )
) TYPE = INNODB;
CREATE TABLE salesinfo
(
SalesID INT NOT NULL,
CustomerID INT NOT NULL,
PRIMARY KEY(CustomerID, SalesID),
FOREIGN KEY (CustomerID) REFERENCES customerinfo
(CustomerID) ON DELETECASCADE
) TYPE = INNODB;

注意例子中的参数“ON DELETE CASCADE”。该参数保证当 customerinfo 表中的一条客户记录被删除的时候,salesinfo 表中所有与该客户相关的记录也会被自动删除。如果要在 MySQL 中使用外键,一定要记住在创建表的时候将表的类型定义为事务安全表 InnoDB类型。该类型不是 MySQL 表的默认类型。定义的方法是在 CREATE TABLE 语句中加上 TYPE=INNODB。如例中所示。

7、使用索引

索引是提高数据库性能的常用方法,它可以令数据库服务器以比没有索引快得多的速度检索特定的行,尤其是在查询语句当中包含有MAX(), MIN()和ORDERBY这些命令的时候,性能提高更为明显。那该对哪些字段建立索引呢?一般说来,索引应建立在那些将用于JOIN, WHERE判断和ORDER BY排序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引。对于一个ENUM类型的字段来说,出现大量重复值是很有可能的情况,例如customerinfo中的“province”.. 字段,在这样的字段上建立索引将不会有什么帮助;相反,还有可能降低数据库的性能。我们在创建表的时候可以同时创建合适的索引,也可以使用ALTER TABLE或CREATE INDEX在以后创建索引。此外,MySQL

从版本3.23.23开始支持全文索引和搜索。全文索引在MySQL 中是一个FULLTEXT类型索引,但仅能用于MyISAM 类型的表。对于一个大的数据库,将数据装载到一个没有FULLTEXT索引的表中,然后再使用ALTER TABLE或CREATE INDEX创建索引,将是非常快的。但如果将数据装载到一个已经有FULLTEXT索引的表中,执行过程将会非常慢。

8、优化的查询语句

绝大多数情况下,使用索引可以提高查询的速度,但如果SQL语句使用不恰当的话,索引将无法发挥它应有的作用。下面是应该注意的几个方面。首先,最好是在相同类型的字段间进行比较的操作。在MySQL 3.23版之前,这甚至是一个必须的条件。例如不能将一个建有索引的INT字段和BIGINT字段进行比较;但是作为特殊的情况,在CHAR类型的字段和VARCHAR类型字段的字段大小相同的时候,可以将它们进行比较。其次,在建有索引的字段上尽量不要使用函数进行操作。

例如,在一个DATE类型的字段上使用YEAE()函数时,将会使索引不能发挥应有的作用。所以,下面的两个查询虽然返回的结果一样,但后者要比前者快得多。

SELECT * FROM order WHERE YEAR(OrderDate)<2001;
SELECT * FROM order WHERE OrderDate<"2001-01-01";

同样的情形也会发生在对数值型字段进行计算的时候:

SELECT * FROM inventory WHERE Amount/7<24;
SELECT * FROM inventory WHERE Amount<24*7;

上面的两个查询也是返回相同的结果,但后面的查询将比前面的一个快很多。第三,在搜索字符型字段时,我们有时会使用 LIKE 关键字和通配符,这种做法虽然简单,但却也是以牺牲系统性能为代价的。例如下面的查询将会比较表中的每一条记录。

SELECT * FROM books
WHERE name like "MySQL%"

但是如果换用下面的查询,返回的结果一样,但速度就要快上很多:

SELECT * FROM books
WHERE name>="MySQL"and name<"MySQM"

最后,应该注意避免在查询中让MySQL进行自动类型转换,因为转换过程也会使索引变得不起作用。

F. 如何使用AWR报告来诊断数据库性能问题

一般来说,当检测到性能问题时,我们会收集覆盖了发生问题的时间段的AWR报告-但是最好只收集覆盖1个小时时间段的AWR报告-如果时间过长,那么AWR报告就不能很好的反映出问题所在。还应该收集一份没有性能问题的时间段的AWR报告,作为一个参照物来对比有问题的时间段的AWR报告。这两个AWR报告的时间段应该是一致的,比如都是半个小时的,或者都是一个小时的。
Interpretation
在处理性能问题时,我们最关注的是数据库正在等待什么。
当进程因为某些原因不能进行操作时,它需要等待。花费时间最多的等待事件是我们最需要关注的,因为降低它,我们能够获得最大的好处。
AWR报告中的"Top 5 Timed Events"部分就提供了这样的信息,可以让我们只关注主要的问题。

Top 5 Timed Events
正如前面提到的,"Top 5 Timed Events"是AWR报告中最重要的部分。它指出了数据库的sessions花费时间最多的等待事件,如下:

Top 5 Timed Events Avg %Total

~~~~~~~~~~~~~~~~~~ wait Call

Event Waits Time (s) (ms) Time Wait Class

------------------------------ ------------ ----------- ------ ------ ----------

db file scattered read 10,152,564 81,327 8 29.6 User I/O

db file sequential read 10,327,231 75,878 7 27.6 User I/O

CPU time 56,207 20.5

read by other session 4,397,330 33,455 8 12.2 User I/O

PX Deq Credit: send blkd 31,398 26,576 846 9.7 Other

-------------------------------------------------------------

Top 5 Events部分包含了一些跟Events(事件)相关的信息。它记录了这期间遇到的等待的总次数,等待所花费的总时间,每次等待的平均时间;这一部分是按照每个Event占总体call time的百分比来进行排序的。

根 据Top 5 Events部分的信息的不同,接下来我们需要检查AWR报告的其他部分,来验证发现的问题或者做定量分析。等待事件需要根据报告期的持续时间和当时数据 库中的并发用户数进行评估。如:10分钟内1000万次的等待事件比10个小时内的1000万等待更有问题;10个用户引起的1000万次的等待事件比 10,000个用户引起的相同的等待要更有问题。

就像上面的例子,将近60%的时间是在等待IO相关的事件。

其他20%的时间是花在使用或等待CPU time上。过高的CPU使用经常是性能不佳的SQL引起的(或者这些SQL有可能用更少的资源完成同样的操作);对于这样的SQL,过多的IO操作也是一个症状。关于CPU使用方面,我们会在之后讨论。

在以上基础上,我们将调查是否这个等待事件是有问题的。若有问题,解决它;若是正常的,检查下个等待事件。

过多的IO相关的等待一般会有两个主要的原因:

Top 5 Events部分的显示的信息会帮助我们检查:

需要注意,接下来的分析步骤取决于我们在TOP 5部分的发现。在上面的例子里,3个top wait event表明问题可能与SQL语句执行计划不好有关,所以接下来我们要去分析"SQL Statistics"部分。
同样的,因为我们并没有看到latch相关的等待,latch在我们这个例子里并没有引发严重的性能问题;那么我们接下来就完全不需要分析latch相关的信息。
一 般来讲,如果数据库性能很慢,TOP 5等待事件里"CPU", "db file sequential read" 和"db file scattered read" 比较明显(不管它们之间的顺序如何),我们总是需要检查Top SQL (by logical and physical reads)部分;调用SQL Tuning Advisor或者手工调优这些SQL来确保它们是有效率的运行。
是否数据库做了大量的读操作:
上面的图显示了在这段时间里两类读操作都分别大于1000万,这些操作是否过多取决于报告的时间是1小时或1分钟。我们可以检查AWR报告的elapsed time如果这些读操作确实是太多了,接下来我们需要检查AWR报告中 SQL Statistics 部分的信息,因为读操作都是由SQL语句发起的。
是否是每次的IO读操作都很慢:
上面的图显示了在这段时间里两类读操作平均的等待时间是小于8ms的
至于8ms是快还是慢取决于底层的硬件设备;一般来讲小于20ms的都可以认为是可以接受的。

我们还可以在AWR报告"Tablespace IO Stats"部分得到更详细的信息

Tablespace IO Stats DB/Inst: VMWREP/VMWREP Snaps: 1-15

-> ordered by IOs (Reads + Writes) desc

Tablespace

------------------------------

Av Av Av Av Buffer Av Buf

Reads Reads/s Rd(ms) Blks/Rd Writes Writes/s Waits Wt(ms)

-------------- ------- ------ ------- ------------ -------- ---------- ------

TS_TX_DATA

14,246,367 283 7.6 4.6 145,263,880 2,883 3,844,161 8.3

USER

204,834 4 10.7 1.0 17,849,021 354 15,249 9.8

UNDOTS1

19,725 0 3.0 1.0 10,064,086 200 1,964 4.9

AE_TS

4,287,567 85 5.4 6.7 932 0 465,793 3.7

TEMP

2,022,883 40 0.0 5.8 878,049 17 0 0.0

UNDOTS3

1,310,493 26 4.6 1.0 941,675 19 43 0.0

TS_TX_IDX

1,884,478 37 7.3 1.0 23,695 0 73,703 8.3

>SYSAUX

346,094 7 5.6 3.9 112,744 2 0 0.0

SYSTEM

101,771 2 7.9 3.5 25,098 0 653 2.7

如上图,我们关心Av Rd(ms)的指标。如果它高于20ms并且同时有很多读操作的,我们可能要开始从OS的角度调查是否有潜在的IO问题。

注:对于一些比较空闲的tablespace/files,我们可能会得到一个比较大的Av Rd(ms)值;对于这样的情况,我们应该忽略这样的tablespace/files;因为这个很大的值可能是由于硬盘自旋(spin)引起的,没有太大的参考意义。比如对
于一个有1000万次读操作而且很慢的系统,引起问题的基本不可能是一个只有10次read的tablespace/file.
虽 然高"db file scattered read"和"db file sequential read"等待可以是I / O相关的问题,但是很多时候这些等待也可能是正常的;实际上,对一个已经性能很好的数据库系统,这些等待事件往往在top 5等待事件里,因为这意味着您的数据库没有那些真正的“问题”。
诀窍是能够评估引起这些等待的语句是否使用了最优的访问路径。如果"db file scattered read"比较高,那么相关的SQL语句可能使用了全表扫描而没有使用索引(也许是没有创建索引,也许是没有合适的索引);相应的,如果"db file sequential read"过多,则表明也许是这些SQL语句使用了selectivity不高的索引从而导致访问了过多不必要的索引块或者使用了错误的索引。这些等待可 能说明SQL语句的执行计划不是最优的。
接下来就需要通过AWR来检查这些top SQL是否可以进一步的调优,我们可以查看AWR报告中 SQL Statistics 的部分.
上面的例子显示了20%的时间花在了等待或者使用CPU上,我们也需要检查 SQL statistics 部分来进一步的分析。
数据库做了太多的读操作
每次的IO读操作都很慢
事件"db file scattered read"一般表明正在做由全表扫描或者index fast full scan引起的多块读。
事件"db file sequential read"一般是由不能做多块读的操作引起的单块读(如读索引)

SQL Statistics
AWR包含了一些不同的SQL统计值:

根据Top 5 部分的Top Wait Event不同,我们需要检查不同的SQL statistic。

在我们这个例子里,Top Wait Event是"db file scattered read","db file sequential read"和CPU;我们最需要关心的是SQL ordered by CPU Time, Gets and Reads。

我们会从"SQL ordered by gets"入手,因为引起高buffer gets的SQL语句一般是需要调优的对象。

SQL ordered by Gets

-> Resources reported for PL/SQL code includes the resources used by all SQL

statements called by the code.

-> Total Buffer Gets: 4,745,943,815

-> Captured SQL account for 122.2% of Total

Gets CPU Elapsed

Buffer Gets Executions per Exec %Total Time (s) Time (s) SQL Id

-------------- ------------ ------------ ------ -------- --------- -------------

1,228,753,877 168 7,314,011.2 25.9 8022.46 8404.73 5t1y1nvmwp2

SELECT ADDRESSID",CURRENT$."ADDRESSTYPEID",CURRENT$URRENT$."ADDRESS3",

CURRENT$."CITY",CURRENT$."ZIP",CURRENT$."STATE",CURRENT$."PHONECOUNTRYCODE",

CURRENT$."PHONENUMBER",CURRENT$."PHONEEXTENSION",CURRENT$."FAXCOU

1,039,875,759 62,959,363 16.5 21.9 5320.27 5618.96 grr4mg7ms81

Mole: DBMS_SCHEDULER

INSERT INTO "ADDRESS_RDONLY" ("ADDRESSID","ADDRESSTYPEID","CUSTOMERID","
ADDRESS1","ADDRESS2","ADDRESS3","CITY","ZIP","STATE","PHONECOUNTRYCODE","PHONENU

854,035,223 168 5,083,543.0 18.0 5713.50 7458.95 4at7cbx8hnz

SELECT "CUSTOMERID",CURRENT$."ISACTIVE",CURRENT$."FIRSTNAME",CURRENT$."LASTNAME",CU<
RRENT$."ORGANIZATION",CURRENT$."DATEREGISTERED",CURRENT$."CUSTOMERSTATUSID",CURR
ENT$."LASTMODIFIEDDATE",CURRENT$."SOURCE",CURRENT$."EMPLOYEEDEPT",CURRENT$.

对这些Top SQL,可以手工调优,也可以调用SQL Tuning Advisor。

分析:

Other SQL Statistic Sections
就像之前提到的那样,AWR报告中有很多不同的部分用来分析各种不同的问题。如果特定的问题并没有出现,那么分析AWR报告的这些部分并不能有很大的帮助。
下面提到了一些可能的问题:

Waits for 'Cursor: mutex/pin' 如 果发现了一些像"Cursor: pin S wait on X" 或"Cursor: mutex X" 类的mutex等待,那么可能是由于parsing引起的问题。检查"SQL ordered by Parse Calls" 和"SQL ordered by Version Count"部分的Top SQL,这些SQL可能引起这类的问题。
单次执行buffer gets过多
SQL_ID为'5t1y1nvmwp2'和'4at7cbx8hnz'的SQL语句总共被执行了168次,但是每次执行引起的buffer gets超过500万。这两个SQL应该是主要的需要调优的候选者。
执行次数过多
SQL_ID 'grr4mg7ms81' 每次执行只是引起16次buffer gets,减少这条SQL每次执行的buffer get可能并不能显着减少总共的buffer gets。这条语句的问题是它执行的太频繁了,6500万次。
改变这条SQL的执行次数可能会更有意义。这个SQL看起来是在一个循环里面被调用,如果可以让它一次处理的数据更多也许可以减少它执行的次数。
-> Total Buffer Gets: 4,745,943,815
假设这是一个一个小时的AWR报告,4,745,943,815是一个很大的值;所以需要进一步分析这个SQL是否使用了最优的执行计划
Indivial Buffer Gets
上面的例子里单个的SQL的buffer get非常多,最少的那个都是8亿5千万。这三个SQL指向了两个不同的引起过多buffers的原因:
注意:对于某些非常繁忙的系统来讲,以上的数字可能都是正常的。这时候我们需要把这些数字跟正常时段的数字作对比,如果没有什么太大差别,那么这些SQL并不是引起问题的元兇(虽然通过调优这些SQL我们仍然可以受益)

Load Profile
根据Top 5等待事件的不同,"Load Profile"可以提供一些有用的背景资料或潜在问题的细节信息。
Load Profile

~~~~~~~~~~~~ Per Second Per Transaction

--------------- ---------------

Redo size: 4,585,414.80 3,165,883.14

Logical reads: 94,185.63 65,028.07

Block changes: 40,028.57 27,636.71

Physical reads: 2,206.12 1,523.16

Physical writes: 3,939.97 2,720.25

User calls: 50.08 34.58

Parses: 26.96 18.61

Hard parses: 1.49 1.03

Sorts: 18.36 12.68

Logons: 0.13 0.09

Executes: 4,925.89 3,400.96

Transactions: 1.45

% Blocks changed per Read: 42.50 Recursive Call %: 99.19

Rollback per transaction %: 59.69 Rows per Sort: 1922.64

在这个例子里,Top 5 Events部分显示问题可能跟SQL的执行有关,那么我们接下来检查load profile部分。

如果您检查AWR report是为了一般性的性能调优,那么可以看到有比较多的redo activity和比较高的physical writes. Physical writes比physical read要高,并且有42%的块被更改了.

此外,hard parse的次数要少于soft parse.
如果mutex等待事件比较严重,如"library cache: mutex X",那么查看所有parse的比率会更有用。

当然,如果把Load Profile部分跟正常时候的AWR报告做比较会更有用,比如,比较redo size, users calls, 和 parsing这些性能指标。

Instance Efficiency
Instance Efficiency部分更适用于一般性的调优,而不是解决某个具体问题(除非等待事件直接指向这些指标)。

Instance Efficiency Percentages (Target 100%)

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

Buffer Nowait %: 99.91 Redo NoWait %: 100.00

Buffer Hit %: 98.14 In-memory Sort %: 99.98

Library Hit %: 99.91 Soft Parse %: 94.48

Execute to Parse %: 99.45 Latch Hit %: 99.97

Parse CPU to Parse Elapsd %: 71.23 % Non-Parse CPU: 99.00

从我们的这个例子来看,最有用的信息是%Non-Parse CPU,它表明几乎所有的CPU都消耗在了Execution而不是Parse上,所以调优SQL会对性能有改善。

G. 为了测试数据库查询的效率是否提升,经常使用索引来实现,请问什么是索引 有什么作用 原理是什么

一、什么是索引?

索引就像是书的目录,是与表或者视图关联磁盘上的结构,可以加快从表中或者视图中检索行的速度。素银中包含表或者视图中的一行或者多列生成的键。这些键存储在一个结构(BTree)中,使SQL可以快速有效的查找与键值关联的行。


二、有什么用?即索引的优点

  1. 建立索引的行可以保证行的唯一性,生成唯一的word

  2. 建立索引可以有效的缩短数据的检索时间

  3. 建立索引可以加快表与表之间的 连接

  4. 为用来排序或者是分组的字段添加索引可以加快和排序顺序

  • 无索引,直接去读表数据存放的磁盘快,督导数据缓冲区中再去查找需要的数据

  • 有索引,先读入索引表,通过索引表直接去找到需要数据的物理地址,并把数据读入数据缓冲区中。


三、索引的原理

通过不断地缩小想要获取数据的范围来筛选出最终想要的结果,同时把随机的事件变成顺序的事件,也就是说,有了这种索引机制,我们可以总是用同一种查找方式来锁定数据。

H. 中英文医学文献检索的数据库各有哪些

常见的英文医学检索数据库:

1、Medline——世界上最着名的医学文献检索系统之一

2、AIDS Databases——有关艾滋病的临床实验、药物研制以及相关文献数据库

3、CANCERLIT——癌症数据库(National Cancer Institute)

4、CHID online——综合卫生信息数据库,提供有关卫生、卫生教育资源的题录、文摘等信息

5、ClinicalTrials.gov——向医患人员提供的临床实验信息数据库

6、DIRLINE——收集美国约17,000个政府机构、研究机构、公司、学术机构等信息

7、药物信息库——包含有9,000余种美国处方与非处方药物信息

8、HSTAT——包括有健康指南、评价、和消费者指南信息的全文数据库

9、NCCAM Resources——补充和替代医学资源

常见的中文医学检索数据库:

1、中国知网——知网,是国家知识基础设施的概念。

2、生物医学文献数据库——中国医科院信息研究所研制,综合性生物医学数据库,国内权威。

3、中国科学引文索引数据库——收集我国出版315种重要期刊,91-94年13万篇论文及45万引文摘要。

4、中医中药数据库——中国科学院科学数据库提供

5、中国中医药文献检索中心——由中国中医研究院信息中心制作,提供中医药方面的Web界面文献检

I. Oracle数据库中的索引详解

一 ROWID的概念

存储了row在数据文件中的具 *** 置 位编码的数据 A Z a z + 和 /

row在数据块中的存储方式

SELECT ROWID last_name FROM hr employees WHERE department_id = ;

比如 OOOOOOFFFBBBBBBRRR

OOOOOO data object number 对应dba_objects data_object_id

FFF file# 对应v$datafile file#

BBBBBB block#

RRR row#

Dbms_rowid包

SELECT dbms_rowid rowid_block_number( AAAGFqAABAAAIWEAAA ) from al;

具体到特定的物理文件

二 索引的概念

类似书的目录结构

Oracle 的 索引 对象 与表关联的可选对象 提高SQL查询语句的速度

索引直接脊滑指向包含所查询值的行的位置 减少磁盘I/O

与所索引的表是相互独立的物理结构

Oracle 自动使用并维护索引 插入 删除 更新表后 自动更新索引

语法 CREATE INDEX index ON table (column[ column] );

B tree结构(非bitmap)

[一]了解索引的工樱拿腊作原理

表 emp

目标 查询Frank的工资salary

建立索引 create index emp_name_idx on emp(name);

[试验]测试索引的作用

运行/rdbms/admin/utlxplan 脚本

建立测试表

create table t as select * from dba_objects;

insert into t select * from t;

create table indextable

as select rownum id owner object_name subobject_name

object_id data_object_id object_type created

from t;

set autotrace trace explain

set timing on

分析表 可以得到cost

查询 object_name= DBA_INDEXES

在object_name列上建立索引

再查询

[思考]索引的代价

插入 更新

三 唯一索引

何时创建 当某列任意两行的值都不相同

当建立Primary Key(主键)或者Unique constraint(唯一约束)时 唯一索引将被自动建立

语法 CREATE UNIQUE INDEX index ON table (column);

演示

四 组合索引

何时创建 当两个或多个列经常一起出现在where条件中时 则在这些列上同时创建组合索引

组合索引中列的顺序是任意的 也无需相邻 但是建议将最频繁访问的列放在列表的最前面

演示(组合列 单独列)

五 位图索引

何时创建

列中有非常多的重复的值时候 例如某列保存了 性别 信息

Where 条件中包含了很多OR操作符

较少的update操作 因敏稿为要相应的跟新所有的bitmap

结构 位图索引使用位图作为键值 对于表中的每一数据行位图包含了TRUE( ) FALSE( ) 或NULL值

优点 位图以一种压缩格式存放 因此占用的磁盘空间比标准索引要小得多

语法 CREATE BITMAP INDEX index ON table (column[ column] );

掩饰

create table bitmaptable as select * from indextable where owner in( SYS PUBLIC );

分析 查找 建立索引 查找

六 基于函数的索引

何时创建 在WHERE条件语句中包含函数或者表达式时

函数包括 算数表达式 PL/SQL函数 程序包函数 SQL函数 用户自定义函数

语法 CREATE INDEX index ON table (FUNCTION(column));

演示

必须要分析表 并且query_rewrite_enabled=TRUE

或者使用提示/*+ INDEX(ic_index)*/

七 反向键索引

目的 比如索引值是一个自动增长的列

多个用户对集中在少数块上的索引行进行修改 容易引起资源的争用 比如对数据块的等待 此时建立反向索引

性能问题

语法

重建为标准索引 反之不行

八 键压缩索引

比如表landscp的数据如下

site feature job

Britten Park Rose Bed Prune

Britten Park Rose Bed Mulch

Britten Park Rose Bed Spray

Britten Park Shrub Bed Mulch

Britten Park Shrub Bed Weed

Britten Park Shrub Bed Hoe

……

查询时 以上 列均在where条件中同时出现 所以建立基于以上 列的组合索引 但是发现重复值很多 所以考虑压缩特性

Create index zip_idx

on landscp(site feature job)

press ;

将索引项分成前缀(prefix)和后缀(postfix)两部分 前两项被放置到前缀部分

Prefix : Britten Park Rose Bed

Prefix : Britten Park Shrub Bed

实际所以的结构为

Prune

Mulch

Spray

Mulch

Weed

Hoe

特点 组合索引的前缀部分具有非选择性时 考虑使用压缩 减少I/O 增加性能

九 索引组织表(IOT)

将表中的数据按照索引的结构存储在索引中 提高查询速度

牺牲插入更新的性能 换取查询性能 通常用于数据仓库 提供大量的查询 极少的插入修改工作

必须指定主键 插入数据时 会根据主键列进行B树索引排序 写入磁盘

十 分区索引

簇:

A cluster is a group of tables that share the same data blocks because they share mon columns and are often used together

lishixin/Article/program/Oracle/201311/17769