數(shù)據(jù)庫(kù)系統(tǒng)中的查詢技術(shù)探討畢業(yè)論文-全文預(yù)覽
【正文】 總結(jié) 20％的代碼用去了 80％的時(shí)間，這是程序設(shè)計(jì)中的一個(gè)著名定律，在數(shù)據(jù)庫(kù)應(yīng)用程序中也同樣如此。 2．把臨時(shí)表和 vendor 表連接，把結(jié)果輸出到一個(gè)臨時(shí)表，并按 part_num 排序 : SELECT pv_by_vn，＊ FROM pv_by_vn， vendor WHERE = ORDER BY INTO TMP pvvn_by_pn DROP TABLE pv_by_vn 這個(gè)查詢讀取 pv_by_vn(50 頁(yè) )，它通過(guò)索引存取 vendor 表 萬(wàn)次，但由于按 vendor_num 次序排列，實(shí)際上只是通過(guò)索引順序地讀 vendor 表（ 40＋ 2=42 頁(yè)），輸出的表每頁(yè)約 95行，共 160 頁(yè)。此語(yǔ)句的優(yōu)化查詢規(guī)劃是：首先從 part 中順序讀取 400 頁(yè)，然后再對(duì) parven 表非順序存取 1 萬(wàn)次，每次 2 頁(yè)（一個(gè)索引頁(yè)、一個(gè)數(shù)據(jù)頁(yè)），總計(jì) 2萬(wàn)個(gè)磁盤頁(yè)，最后對(duì) vendor 表非順序存取 萬(wàn)次 , 合 3萬(wàn)個(gè)磁盤頁(yè)。索引的建立避免了在嵌套中反復(fù)掃描。 523， 045 IBM Corp 500， 049 Novel 10M work card SQL語(yǔ)句隱藏了數(shù)據(jù)庫(kù)系統(tǒng)中的查詢技術(shù)探討 第 12 頁(yè) 共 16 頁(yè) 這一情況，使得我們?cè)趯憫?yīng)用程序時(shí)很容易寫出要求存取大量非順序頁(yè)的查詢。但這種匹配特別耗費(fèi)時(shí)間。 4）避免相關(guān)子查詢 一個(gè)列的標(biāo)簽同時(shí)在主查詢和 where 子句的查詢中出現(xiàn)，那么很可能當(dāng)主查詢中的列值改變之后，子查詢必須重新查詢一次。比如采用順序存取策略，一個(gè)嵌套 3 層的查詢，如果每層都查詢 1000 行，那么這個(gè)查詢就要查詢 10 億行數(shù)據(jù)。索引中不包括一個(gè)或幾個(gè)待排序的列； 另外，當(dāng)數(shù)據(jù)庫(kù)表更新大量數(shù)據(jù)后，刪除并重建索引可以提高查詢速度。 在條件表達(dá)式中經(jīng)常用到的不同值較多的列上建立索引，在不同值少的列上不需要。在經(jīng)常進(jìn)行連接，但是沒有指定為外鍵的列上建立索引，而不經(jīng)常連接的字段則由優(yōu)化器自動(dòng)生成索引。 各個(gè)問(wèn)題是按上述次序來(lái)解決的，因?yàn)榍罢弑群笳吒匾Ｔ诜植际綌?shù)據(jù)庫(kù)中，則還必須考慮數(shù)據(jù)的傳輸量。 (7)行資源生成器。 (6)全局信息表。一個(gè)執(zhí)行計(jì)劃描述一個(gè)查詢請(qǐng)求是如何具體地被執(zhí)行，幾乎所有的數(shù)據(jù)庫(kù)系統(tǒng)都用同樣的方法來(lái)表達(dá)查詢計(jì)劃 —— 語(yǔ)法樹?；诖鷥r(jià)的查詢優(yōu)化器在生成執(zhí)行計(jì)劃時(shí)，將其作為進(jìn)行定量分析的參考。在分布式數(shù)據(jù)庫(kù)中，這一步還必須能夠選擇每個(gè)操作的執(zhí)行站點(diǎn)。 語(yǔ)句在這一步，進(jìn)行了簡(jiǎn)單的優(yōu)化。在這個(gè)階段，查詢語(yǔ)句被解析成查詢的內(nèi)部表示，以便后面的各階段的處理。 數(shù)據(jù)庫(kù)系統(tǒng)中的查詢技術(shù)探討 第 8 頁(yè) 共 16 頁(yè) 分布式查詢優(yōu)化過(guò)程 分布式查詢優(yōu)化已經(jīng)開展了很多年，從各種應(yīng)用角度，所有的工作都可以歸分為兩種基 本的方法： (1) 通過(guò)減少分布式查詢中數(shù)據(jù)傳輸?shù)臄?shù)量來(lái)降低傳輸?shù)馁M(fèi)用。 (2)把算符樹中的選擇和投影運(yùn)算盡可能向下推移。 在分布式數(shù)據(jù)庫(kù)系統(tǒng)中，還影響到物理查詢計(jì)劃設(shè)計(jì)的復(fù)雜性和可選方案。執(zhí)行引數(shù)據(jù)庫(kù)查詢優(yōu)化技術(shù) 第 7 頁(yè) 共 16 頁(yè) 擎再為每一個(gè)關(guān)系操作或操 作組實(shí)現(xiàn)一系列物理操作。 查詢處理開始之前系統(tǒng)必須將查詢語(yǔ)句翻譯成系統(tǒng)內(nèi)部的表示形式。 SQL 語(yǔ)言的一般格式如下： SELECT columnlist FROM tablelist WHERE conditionlist 其中， columnlist 是要返回的查詢 結(jié)果的屬性列表， tablelist 是查詢所涉及到的所有關(guān)系， conditionlist 是條件表達(dá)式，條件表達(dá)式中的謂詞可以將查詢作為其操縱數(shù)。 傳統(tǒng)的集合運(yùn)算是二目運(yùn)算，包括并、差、交、廣義笛卡爾積四種運(yùn)算。查詢計(jì)劃是由一系列內(nèi)部操作組成的，這些內(nèi)部操作按照一定的次序構(gòu)成查詢的一個(gè)執(zhí)行方案，通常這樣的執(zhí)行方案有很多個(gè)，需要對(duì)每個(gè)執(zhí)行計(jì)劃計(jì)算代價(jià)，從中選擇代價(jià)最小的一個(gè)。 （ 2）根據(jù)一定的等價(jià)變換規(guī)則把語(yǔ)法樹換成優(yōu)化 (標(biāo)準(zhǔn) )形 式 。 為了實(shí)現(xiàn)快速查詢，除了在數(shù)據(jù)庫(kù)的物理設(shè)計(jì)、關(guān)系規(guī)范化等方面進(jìn)行改進(jìn)外，一個(gè)關(guān)鍵措施就是提供最優(yōu)的查詢路徑?jīng)Q策能力，提高查詢響應(yīng)速度。 我國(guó)的數(shù)據(jù)庫(kù) (主要是中文數(shù)據(jù)庫(kù) )建設(shè)起步于 70年代中后期 ,經(jīng)過(guò)幾十年的發(fā)展，我國(guó)的數(shù)據(jù)庫(kù)技術(shù)進(jìn)步很大，在商用數(shù)據(jù)庫(kù)管理系統(tǒng)（ DBMS）中也出現(xiàn)了像 OpenBase、SECBase 等自主版權(quán)的數(shù)據(jù)庫(kù)管理系統(tǒng)。如果采用比全表掃描更好的查詢策略和技術(shù)，往往可以使查詢時(shí)間降為幾分鐘或是更短，由此可以看到查詢優(yōu)化技術(shù)的重要性和必要性。 許多程序員認(rèn)為查詢優(yōu)化是數(shù)據(jù)庫(kù)管理系統(tǒng) (DBMS)的任務(wù)，與程序員所編寫的 SQL語(yǔ)句關(guān)系不大。即：數(shù)據(jù)庫(kù)技術(shù)是研究、管理和應(yīng)用數(shù)據(jù)庫(kù)的一門軟件科學(xué)。 Inefficient. 前言 第 1 頁(yè) 共 16 頁(yè) 數(shù)據(jù)庫(kù)系統(tǒng)中的查詢技術(shù)探討 前言 數(shù)據(jù)庫(kù)的產(chǎn)生和發(fā)展 以前，當(dāng)人們需要了解大量復(fù)雜的資源信息時(shí)，都只有通過(guò)相關(guān)的書籍或者光盤，磁盤等等進(jìn)行查找，這通常需要耗費(fèi)大量的人力和時(shí)間，效率尤為低下。在查詢執(zhí)行的過(guò)程中，低效的 SQL查詢語(yǔ)句 ,概貌信息的匱乏、連接順序的錯(cuò)誤選擇都是直接導(dǎo)致查詢低效的原因。即：數(shù)據(jù)庫(kù)技術(shù)是研究、管理和應(yīng)用數(shù)據(jù)庫(kù)的一門軟件科學(xué)。 6 4 數(shù)據(jù)庫(kù)查詢優(yōu)化技術(shù) 5 查詢處理流程 3 查詢優(yōu)化的基本概念 XI摘要 ………………………………………………………………………… XII 1 前言 1 2 選題背景 ???? ????????? ???????????????? 2 課題的背景及來(lái)源?????????? ??? ????????? 2 研究的目的和意義?????????????????????? 2 國(guó)內(nèi)外發(fā)展現(xiàn)狀和趨勢(shì)與研究的主攻方向??? ????? ???? 3 3 查詢優(yōu)化概述 3
法律信息相關(guān)推薦
鄂ICP備17016276號(hào)-1