數(shù)據(jù)庫開發(fā)技術(shù)復(fù)習(xí)「部分」

oracle的無阻塞讀。修改才會加鎖，行級鎖。讀寫器不會阻塞寫入器。提高了并發(fā)效率，缺點，無阻塞設(shè)計需要保證一次最多只有一個用戶讀取一行。

where xxx【 FOR UPDATE】關(guān)鍵字

NULL處理的差異，基本差別（并發(fā)控制機制）

SQL優(yōu)化方向：索引，執(zhí)行計劃，SQL語句優(yōu)化，物理分庫分表，數(shù)據(jù)庫表結(jié)構(gòu)，整體結(jié)構(gòu)設(shè)計。

1.索引

結(jié)構(gòu)-能做什么-不能做什么-try

1.關(guān)系&非關(guān)系型數(shù)據(jù)庫

2.B-樹，B+樹

B-樹

分層

B+樹

分層，數(shù)據(jù)全在葉結(jié)點，并且葉節(jié)點順序排列。葉節(jié)點內(nèi)包含rowid。

應(yīng)用場景

• 全鍵值 where x=123
• 鍵值范圍查詢 where 45<x<125
• 鍵前綴查找 where x LIKE ‘J%’

3.索引一定能提高查詢效率嗎？不一定！

索引是一種以原子粒度訪問數(shù)據(jù)庫的手段而不是為了檢索大量數(shù)據(jù)

索引的代價

• 磁盤空間的開銷（存儲索引）
• 處理的開銷（大幅提高更新開銷，索引也要修改）
• 數(shù)據(jù)庫系統(tǒng)處理的開銷（更新需要更多的工作）

索引發(fā)揮作用的條件

索引適用性依據(jù)為檢索比例

• 有時候通過索引訪問基本表的很少一部分

• 如果要處理表中的多行，可以使用索引而不用表。Index(x,y)//

  【復(fù)合索引，本質(zhì)上索引是按照排名第一的字段進行的索引

索引是查詢工作的第一步，讀取基本表的數(shù)據(jù)才是查詢的結(jié)束。同樣的索引，但不同的物理結(jié)構(gòu)，會引起查詢的千差萬別-磁盤訪問的速率，物理I/O，記錄存儲。事務(wù)處理型數(shù)據(jù)庫中 “太多索引≈設(shè)計不夠穩(wěn)定”。

索引的問題

函數(shù)和類型轉(zhuǎn)換：含有日期函數(shù)/隱式類型轉(zhuǎn)換的檢索條件無法使用索引。where substr(name, 3, 1) = ‘R’ ?

索引與外鍵：建立索引必須有理由。無論是對外鍵，或是其他字段都是如此

同一個字段，多個索引。如果系統(tǒng)為外鍵自動增加索引，常常會導(dǎo)致同一字段屬于多個索引的情況

系統(tǒng)生成鍵：系統(tǒng)生產(chǎn)序列號，遠好于尋找當前最大值并加1 /用一個專用表保存”下一個值“且加鎖更新。但如果插入并發(fā)性過高，在主鍵索引的創(chuàng)建操作上會發(fā)生十分嚴重的資源競爭

索引不起作用的原因

總結(jié)：

我們在使用B+樹索引，而且謂詞中沒有使用索引的最前列。T(x,y)中過濾條件為y相關(guān)。

使用SELECT COUNT(*) FROM T，而且T上有索引，但是優(yōu)化器仍然全表掃描。

對于一個有索引的列作出函數(shù)查詢

隱形函數(shù)查詢

SLOW此時如果用了索引，實際反而會更慢

WRONG沒有正確的統(tǒng)計信息造成CBO無法做出正確的選

總結(jié)：歸根到底，不使用索引的通常愿意就是“不能使用索引，使用索引會返回不正確的結(jié)果”，或者“不該使用索引，如果使用了索引就會變得更慢”

4.B+與Hash索引的差異與查詢適用條件

哈希索引：MySQL

Hash(x)，僅支持等值查詢（碰撞率的問題）

位圖索引：Oracle7.3

每行數(shù)據(jù)用1，0來表示其身份

Value/Row1234

A	1	1	0	1
B	0	0	1	0
C·	0	0	0	0
D	0	0	0	0

適用場景：

• 相異基數(shù)低（）
• 大量臨時查詢的聚合

位圖聯(lián)結(jié)索引：Oracle

允許使用另外某個表的列對一個給定表建立索引。實際上，這就是允許對一個索引結(jié)構(gòu)（而不是表本身）中的數(shù)據(jù)進行逆規(guī)范化。

MySQL沒有位圖索引，1）優(yōu)化替代索引組合；2）低選擇性添加特殊索引.order by xx limit 1000,10 限制用戶查看的頁數(shù)

函數(shù)索引：function-based index

對函數(shù)F(x)的值構(gòu)建索引，通過對索引讀取x所指向的記錄行。

引用場景：

• 不區(qū)分大小寫upper(name) = ‘KING’
• T、F的巨大差異下的索引
• 有選擇的唯一性 Create unique index ax_name on project(xxx內(nèi)容)

2.SQL***

1.SQL執(zhí)行順序

查詢優(yōu)化器

SQL基于需求和關(guān)系理論，查詢優(yōu)化器基于實現(xiàn)和關(guān)系理論。

優(yōu)化器借助關(guān)系理論提供的語義無誤的原始查詢進行有效的等價變換。優(yōu)化器根據(jù)數(shù)據(jù)庫的實際實現(xiàn)情況，對理論上等價的不同優(yōu)化方案做出權(quán)衡， 產(chǎn)生可能的最優(yōu)查詢執(zhí)行方案

RBO：基于規(guī)則的優(yōu)化器，操作符權(quán)重，權(quán)重和最少的

CBO基于成本，如索引、物理存儲、CPU、內(nèi)存等因素

SQL執(zhí)行順序

SQL語句

語義語法檢查

解析【消耗內(nèi)存，等價變化，生成解析樹，評估】

執(zhí)行計劃【可執(zhí)行的二進制代碼】

執(zhí)行引擎

存儲引擎Oracle, MylSAM, InnoDB, MEMORY

數(shù)據(jù)庫

注意，優(yōu)化器的局限性，優(yōu)化的起點為SQL語句，影響最終選擇。有些東西需要程序員手工進行。不能優(yōu)化的內(nèi)容包括1.實際環(huán)境信息-過濾條件；2.中間結(jié)果集（臨時存儲，開銷大）；3.SQL本身有太多操作操作。

優(yōu)化器只能對關(guān)系領(lǐng)域進行優(yōu)化！

優(yōu)化器的有效范圍

• 優(yōu)化器需要借助數(shù)據(jù)庫中找到的信息
• 能夠進行數(shù)學(xué)意義上的等價變換
• 優(yōu)化器考慮整體響應(yīng)時間
• 優(yōu)化器改善的是獨立的查詢

2.優(yōu)化的核心邏輯

優(yōu)化考慮因素

獲得結(jié)果集所需訪問的數(shù)據(jù)總量

定義結(jié)果集所需查詢條件//多個where子句，過濾條件的效率又高有低，受到其他因素的影響大

結(jié)果集的大小//從技術(shù)角度來看，查詢結(jié)果集的大小并不重要，重要的是用戶的感覺，該努力使響應(yīng)時間與返回的記錄數(shù)成比例//百度谷歌，分頁，只顯示數(shù)字//對輸入進行結(jié)果集預(yù)測

獲得結(jié)果集所涉及的表的數(shù)量//表太多，join操作開銷極大，太多的表連接->設(shè)計問題//復(fù)雜查詢和復(fù)雜視圖，基本的原則是當是視圖返回的數(shù)據(jù)遠多于上級查詢所需要的時候，就放棄使用該視圖

同時修改這些數(shù)據(jù)用戶的多少//數(shù)據(jù)塊訪問爭用，阻塞，閂定，保證讀取一致性//整體吞吐量>個體響應(yīng)時間

查詢的過濾條件

高效過濾條件是查詢的主要驅(qū)動力

//1.通過表的連接來篩選數(shù)據(jù) //注意可以在join內(nèi)部on可以指定條件更好一些 select distinct c.custname from customer cjoin orders oon o.cusid=c.cusidand o.ordered >= 日期換算join orderdetail odon od.ordid = o.ordidjoin articles a....where c.city="Nanjing".... //2.古老的自然連接方式，大量的笛卡爾積運算 select distinct xxfrom table1, table2, table3where a and b and c and d ***避免在最高層distinct應(yīng)該是一條基本規(guī)則*** ***難以判斷結(jié)果的錯誤，發(fā)現(xiàn)不準確的連接難！*** *使用exists 關(guān)聯(lián)子查詢/ in 非關(guān)聯(lián)子查詢替代* *distinct隱藏了一個排序，現(xiàn)排序再刪除重復(fù)行* ---------------- select c.custnamefrom customers cwhere c.city = ‘Nanjing'and exists (select null //這里選擇什么不重要from orders o,orderdetail od,articles awhere a.artname = ‘BMW'and a.artid = od.artidand od.ordid = o.ordidand o.custid = c.custid //與外層相關(guān)and o.ordered >= somefunc )//客戶在Nanjing市，而且滿足Exists存在性測試即在最近六個月買了BMW ------ select custnamefrom customerswhere city = ‘Nanjing'and custid in (select o.custid //注意custidfrom orders o,orderdetail od,articles awhere a.artname = ‘BMW'and a.artid = od.artidand od.ordid = o.ordidand o.ordered >= somefunc) //關(guān)聯(lián)子查詢中，orders表中custid字段要有索引，而對非關(guān)聯(lián)子查詢則不需要，因為要用到的索引是customers的主鍵索引 //內(nèi)層查詢不再依賴外層查詢，只需要執(zhí)行一次 --------- 注意?? 一共有4張表的連接，可以（1+（1+（1+1）））嵌套兩層的exist/in -------- 上述的非關(guān)聯(lián)子查詢都是放置于where之下的 對于很多數(shù)據(jù)庫來說，非關(guān)聯(lián)子查詢還可以寫成from子句的內(nèi)嵌視圖 select custnamefrom customerswhere city = ‘Nanjing'and custid in(select o.custidfrom orders o,(select distinct od.ordidfrom orderdetail od,articles awhere a.artname = ‘BMW'and a.artid = od.artid) xwhere o.ordered >= somefuncand x.ordid = o.ordid)

外層條件好的話，使用exist（過濾掉了大量的外層，驗證存在性）

外層條件不好的話，使用in（還有大量的一一與in的表進行比較）

什么時候使用嵌套子查詢？？？？

頂層出現(xiàn)distinct

出現(xiàn)多個過濾條件·

找到分辨率最強的條件

• 解決方案不止一種，查詢和數(shù)據(jù)隱含的假設(shè)密切相關(guān)
• 預(yù)先考慮優(yōu)化器的工作，以確定它能找到所需要的數(shù)據(jù)
• 平衡二叉樹的優(yōu)化/哈夫曼樹的優(yōu)化

3.用戶感受-SQL語句的優(yōu)化技巧

• 努力使響應(yīng)時間與返回的記錄數(shù)成比例
• 分頁
• 返回有限條
• 增加條件的效率
• 預(yù)測結(jié)果集，空結(jié)果集的預(yù)處理

where子句的比較運算符

a=1000 == a=500+500

a-500=500??全表變量+取值計算

注意當左側(cè)含運算符時，包含了對列的運算，不能使用常規(guī)索引，但是可以使用函數(shù)索引，通用性差，并且表達式匹配。表達式的左邊最好干干凈凈！

表達式左側(cè)有對日期的表達式/函數(shù)，無法使用索引，所以效率極差！

盡量直接比較，忘掉any, all between, not。

大數(shù)據(jù)量查詢

越快剔除不需要的數(shù)據(jù)，查詢的后續(xù)階段必須處理的數(shù)據(jù)量就越少，查詢效率就越高。多層嵌套的exist/in。

union僅僅對非共用的表進行union，將其降級為內(nèi)嵌視圖！！！

濫用子查詢

分辨過濾條件，避免頂層出現(xiàn)distinct(隱藏了一個排序，現(xiàn)排序再刪除重復(fù)行)

不包含聚合函數(shù)，不出現(xiàn)多種過濾條件的選擇，可以不需要子查詢/盡量把選擇權(quán)交給查詢優(yōu)化器！！！

查詢不存在的內(nèi)容

查找表中間不匹配的行？使用外連接

不要使用NOT IN!!!非關(guān)聯(lián)嵌套子查詢，糟糕的性能，建立臨時表，臨時表用于查找外層查詢，索引也不會被使用，會進行全表掃描。

from salary left outer join on (x xx)

將聚合子查詢轉(zhuǎn)換為JOIN或內(nèi)嵌視圖

和聚合有關(guān)的條件都應(yīng)該放在having中間，group by之后才會得到分組，進行過濾。所有與聚合無關(guān)的條件都要放在where中間。聚合之后，情況復(fù)雜了。

關(guān)聯(lián)嵌套子查詢？？多次重復(fù)執(zhí)行？？改為非關(guān)聯(lián)子查詢？？

非關(guān)聯(lián)子查詢？？變?yōu)閮?nèi)嵌式圖！！！

盡量用連接而不用子查詢！！！！

進一步改進？打破范式，冗余地存一個新的狀態(tài)！！訪問++/觸發(fā)器使得開銷++/

比較容易的改進？查詢添加新的條件！！時間限定！！

4.日期與字符串

**字符串

? 1.1 遍歷字符串

沒有循環(huán)功能，數(shù)據(jù)透視表T1，T10，T100對應(yīng)ID來獲取每行一個子符

select substr(e.ename,iter.pos,1) as C from (select ename from emp where ename = 'KING') e,(select id as pos from t10) iter where iter.pos <= length(e.ename) // KING 1 //然后進行substring函數(shù) KING 2 KING 3 KING 4select substr(e.ename, iter.pos,length(e.ename))a from (select ename ...) e,(select id as pos from t10) iter where iter.pos <= length(e.ename)

? 1.2 嵌入引號

常量中添加引號

“’” ==“ 雙中夾單為雙

‘"’ == ‘

? 1.3 統(tǒng)計字符出現(xiàn)的次數(shù)

字符串總長度length()/len()，減去去掉該字符后字符串的長度replace(str, words, words_new)

有時需要除以查找字符的長度

? 1.4 刪除不想要的字符

replace函數(shù)

Oracle特有的translate函數(shù)replace(translate(ename,‘AEIOU’,‘a(chǎn)aaaa’) , ‘a(chǎn)’, ‘’)

Mysql？replace層層嵌套

? 1.5 分離數(shù)字和字符數(shù)據(jù)

translate+replace，把非數(shù)字替換成z/0，再刪除

MySQL程序內(nèi)進行分離

? 1.6 判斷含有字母和數(shù)字的字符串

MySQL regexp’[0-9a-zA-Z]'正則表達式

Oracle 先找出所有的字母數(shù)字字符轉(zhuǎn)換成同一個字符，然后長度不改變比較a*length和轉(zhuǎn)換后的式子。

? 1.7 提取姓名每個單詞的首字母

復(fù)雜復(fù)雜

MySQL很多函數(shù)concat, concat_ws, substr, substring_index. 先刪除句號，在找到空格位置，將字符串拆分

**數(shù)值處理

減少程序和數(shù)據(jù)庫引擎的交互

? 2.1 計算平均值

AVG() 聚合函數(shù) =》 如何處理空值？？？

遇到空值怎么辦？null， 存在空值，不計入|||作為0計算。

select avg(sal) from t2 //刪去這一行 ----- select avg(coalesce(sal,0)) //返回第一個非空值，空值的話置為0 from t2 group by deptno

? 2.2 計算最大值最小值

max(sal) , min(sal) from xx group by xx1

? 2.3 求和

sum(sal) 不需要管空值

? 2.4 計算行數(shù)

count（*） from t1 group by xx_no

count(comn) from amp 會刪除空值

? 2.5 累計求和Running Total

Oracle：： sum(sal) over (order by sal,empn排他列) 窗口函數(shù)

MySQL：累加窗口函數(shù)，標量子查詢

? 2.6 計算眾數(shù)

Max() count(*) group by

? 2.7 計算中位數(shù)

Oracle median(sal)

MySQL 返回笛卡爾集

? 2.8 計算百分比

select (sum() / sum(sal)) * 100 as pct

? 2.9 計算平均值時去掉最大值和最小值

where sal not in(（select min()）（select max()）)

Oracle 窗口函數(shù) 建立視圖sal maxsal minsal 進行一次where過濾

? 2.10 修改累計值

Oracle有窗口函數(shù)：；sum(case表達式?jīng)Q定類型)over()

**日期處理

? 3.1 年月日加減法

oracle

• add_mouth(data, -5)
• add_mouth(data, -5*12)

MySQL

+_interval 5 day

-_interval_5_mouth

date_add(this data, interval 5 day)

? 3.2 計算兩個日期之間的天數(shù)

Oracle 日期直接相減

MySQL datediff(晚的，早的)

? 3.3 計算兩個日期之間的工作日天數(shù)

數(shù)據(jù)透視條！ T500，給每一天當作一行返回

? 3.4 計算當前記錄和下一條記錄之間的日期差

? 3.5 判斷閏年

? 3.6 計算一年有多少天

? 3.7 找到當前月份的第一個和最后一個星期一

? 3.8 依據(jù)特定時間單位檢索數(shù)據(jù)

? 3.9 識別重疊的日期區(qū)間

連接

外鍵組建相等進行等值連接

疊加行集Union & Union all

列的數(shù)據(jù)類型必須相同，字段數(shù)目匹配，Union all會保留重復(fù)項，union會刪去重復(fù)記錄。但是union是在union all上使用distinct，排序操作刪除重復(fù)項。排序是非關(guān)系型操作。

select xx,xx from emp where xx union all // select '------',null from t1 union all // select xx,xx from emp2 where xx

差（查找只存在于一張表的數(shù)據(jù)）

select xx,xx from emp minis //Oracle 過濾重復(fù)值 ：： except //DB2 select xx,xx from emp2 ----- MYSQL：： select [distinct] deptno //需要考慮排除重復(fù)行 from dept where deptno not in (select deptno from emp) 空值怎么辦？ where deptno in(10,50,null) //不會出現(xiàn)問題 where deptno not in(10,50,null) //出現(xiàn)空值會出現(xiàn)問題 //In /not in 都是or運算 // false or null => null //避免在存在空值的情況下使用in/not in，使用關(guān)聯(lián)嵌套子查詢exist

從一個表檢索另一個表不相關(guān)的行（外連接）

select xx from dept d left outer join emp e

確定兩個表是否有相同的數(shù)據(jù)？

(T1 - T2) union all (T2 - T1) 邏輯上，如果兩張表相同的話，應(yīng)該為null

create view V as select* from emp where deptno != 10 union all select * from emp where ename = 'WARD'

（全外連接）從多個表中返回缺失值

FULL OUT JOIN

連接和聚合函數(shù)的使用

連接如何不干擾到聚合操作？

3.事務(wù)（ACID）

事務(wù)是一個原子性質(zhì)的操作單元，事務(wù)里面的對數(shù)據(jù)庫的操作要么都執(zhí)行，要么都不執(zhí)行

在事務(wù)開始之前和完成之后，數(shù)據(jù)都必須保持一致狀態(tài)，必須保證數(shù)據(jù)庫的完整性。也就是說，數(shù)據(jù)必須符合數(shù)據(jù)庫的規(guī)則。

數(shù)據(jù)庫允許多個并發(fā)事務(wù)同事對數(shù)據(jù)進行操作，隔離性保證各個事務(wù)相互獨立，事務(wù)處理時的中間狀態(tài)對其它事務(wù)是不可見的，以此防止出現(xiàn)數(shù)據(jù)不一致狀態(tài)?？赏ㄟ^事務(wù)隔離級別設(shè)置：包括讀未提交（Read uncommitted）、讀提交（read committed）、可重復(fù)讀（repeatable read）和串行化（Serializable）

一個事務(wù)處理結(jié)束后，其對數(shù)據(jù)庫的修改就是永久性的，即使系統(tǒng)故障也不會丟失。

---

臟讀：一個事務(wù)中訪問到了另外一個事務(wù)未提交的數(shù)據(jù)。并發(fā)事務(wù)AB同時開始，A包含一個讀操作，B一個寫操作，AB同時提交結(jié)束。A讀了B的寫操作發(fā)生后的數(shù)據(jù)。

幻讀：一個事務(wù)讀取2次，得到的記錄條數(shù)不一致。并發(fā)事務(wù)AB同時開始，A讀數(shù)據(jù)，B該數(shù)據(jù)，B提交更新，A第二次讀數(shù)據(jù)。A讀了B的寫操作發(fā)生后的數(shù)據(jù)。[鎖住滿足條件及相近的記錄，關(guān)鍵在于新增和刪除]

不可重復(fù)讀：一個事務(wù)讀取同一條記錄2次，得到的結(jié)果不一致：單行記錄。[只需要鎖住滿足條件的記錄，關(guān)鍵在于修改]

---

未提交讀：排他寫鎖。會讀取到未提交的修改了的數(shù)據(jù)。更新不能丟失，寫會阻塞寫，寫不會阻塞讀。

已提交讀RC：瞬間共享讀鎖，排他寫鎖。只能讀取到已經(jīng)提交的數(shù)據(jù)。讀取數(shù)據(jù)的事務(wù)允許其他事務(wù)繼續(xù)訪問該行數(shù)據(jù)，但是未提交的寫事務(wù)將會禁止其他事務(wù)訪問該行。

可重復(fù)讀取RR：“共享讀鎖”和“排他寫鎖”。在對于數(shù)據(jù)庫中的某個數(shù)據(jù)，一個事務(wù)范圍內(nèi)多次查詢卻返回了不同的數(shù)據(jù)值，這是由于在查詢間隔，被另一個事務(wù)修改并提交了。讀取數(shù)據(jù)的事務(wù)將會禁止寫事務(wù)（但允許讀事務(wù)），寫事務(wù)則禁止任何其他事務(wù)。

可串行化：提供嚴格的事務(wù)隔離。它要求事務(wù)序列化執(zhí)行，事務(wù)只能一個接著一個地執(zhí)行，不能并發(fā)執(zhí)行。讀用讀鎖，寫用寫鎖，讀鎖和寫鎖互斥

隔離級別越高，越能保證數(shù)據(jù)的完整性和一致性，但是對并發(fā)性能的影響也越大。除了MySQL默認采用RR隔離級別之外，其它幾大數(shù)據(jù)庫都是采用RC隔離級別。

隔離界別臟讀不可重復(fù)讀幻讀

未提交讀RU	可能	可能	可能
已提交讀RC	?	可能	可能
RR可重復(fù)讀	?	?	可能
Serializable可串行化	?	?	?

RR能否防止幻讀？可以

MySQL的RR隔離級別也解決了幻讀的問題，理論上不行。RR 支持 gap lock(next-key lock)，而RC則沒有g(shù)ap lock。RC 隔離級別，通過 where 條件過濾之后，不符合條件的記錄上的行鎖，會釋放掉(雖然這里破壞了“兩階段加鎖原則”)；但是RR隔離級別，即使不符合where條件的記錄，也不會是否行鎖和gap lock；所以從鎖方面來看，RC的并發(fā)應(yīng)該要好于RR

事務(wù)處理如何影響開發(fā)？

隔離級別越高，越能保證數(shù)據(jù)的完整性和一致性，但是對并發(fā)性能的影響也越大。除了MySQL默認采用RR隔離級別之外，其它幾大數(shù)據(jù)庫都是采用RC隔離級別。

MVCC多版本并發(fā)控制

---

悲觀鎖；對數(shù)據(jù)被外界（包括本系統(tǒng)當前的其他事務(wù)，以及來自外部系統(tǒng)的事務(wù)處理）修改持保守態(tài)度，因此，在整個數(shù)據(jù)處理過程中，將數(shù)據(jù)處 于鎖定狀態(tài)。往往依靠數(shù)據(jù)庫提供的鎖機制。/讀取數(shù)據(jù)時給加鎖，其它事務(wù)無法修改這些數(shù)據(jù)。修改刪除數(shù)據(jù)時也要加鎖，其它事務(wù)無法讀取這些數(shù)據(jù)。

樂觀鎖：樂觀鎖，大多是基于數(shù)據(jù)版本（ Version ）記錄機制實現(xiàn)。

4.分區(qū)–

數(shù)據(jù)表的物理實現(xiàn)

讀寫如何和諧？？？不太能

關(guān)系型數(shù)據(jù)庫？讀寫沖突！沖突的目標

并發(fā)用戶數(shù)很大的系統(tǒng) 緊湊的方式存儲VS數(shù)據(jù)分散存儲

沒有并發(fā)的修改密集型 數(shù)據(jù)查詢要快VS數(shù)據(jù)更新也要快

DBMS所處理的基本單元(page,block)基本不可分割。

分頁

頁模式，優(yōu)化查詢效率，目錄頁只想行，但是會有行遷移，多次IO操作。大量的行遷移使得讀取和更新都變慢。page/block的鏈表，索引的目錄頁

索引當成數(shù)據(jù)倉庫IOT

順序文件組織----IOT索引組織表，聚簇索引

索引中添加額外字段，提高某個頻繁運行的查詢的速度。

索引組織表，把數(shù)據(jù)存儲在索引中。

索引組織表（順序表，災(zāi)難：寬表的隨機插入，長字符串）vs只有索引的表

開銷不一定誰大。

記錄是排序的，對索引組織表而言效率驚人

順序文件的組織，禁止更新

分區(qū)

一個大型的表物理存儲為多個小型的表，在DBMS引擎下邏輯表現(xiàn)為一張表。

數(shù)據(jù)的自動分組，屏蔽了底層物理實現(xiàn)，提高了并發(fā)性和并行性，增強了架構(gòu)的可伸縮性

循環(huán)分區(qū)：為了高效管理。不受數(shù)據(jù)影響的內(nèi)部機制，無邏輯。分區(qū)為磁盤的存儲區(qū)域。并發(fā)隨機的數(shù)據(jù)查詢++

數(shù)據(jù)驅(qū)動分區(qū)：依賴于數(shù)據(jù)邏輯。根據(jù)一個或多個字段的值來決定在哪個分區(qū)。- 哈希分區(qū)（算術(shù)運算隨機分區(qū)負載均衡使用的） - 范圍分區(qū) - 列表分區(qū)///滑動窗口最近一年？1月表，2月表

分區(qū)是可以嵌套的

分區(qū)是雙刃劍！

所有的插入都會對一個分區(qū)進行并發(fā)插入，分散的數(shù)據(jù)理論上避免訪問過于集中的問題。但是針對某一個分區(qū)插入的并發(fā)很不利，爭奪同一個數(shù)據(jù)塊，內(nèi)存開銷極大。

對分區(qū)的查詢，當數(shù)據(jù)按分區(qū)鍵均勻分布，收益最大

最佳的數(shù)據(jù)分區(qū)

要整體考慮

任何存儲方式都會帶來復(fù)雜性，選錯存儲方式都會帶來大幅度的性能降低！關(guān)系模型-有點為靈活性，物理組織可能會喪失靈活性。

測試、測試、測試

設(shè)計都是最重要的

任何設(shè)計都有時效性！！！

5.樹狀結(jié)構(gòu)–

數(shù)據(jù)庫模式設(shè)計-層次結(jié)構(gòu)

即樹狀結(jié)構(gòu)，如何把樹狀結(jié)構(gòu)存儲到數(shù)據(jù)庫中？

-歷史：層次結(jié)構(gòu)、網(wǎng)狀、關(guān)系型

-關(guān)系理論出現(xiàn)，數(shù)據(jù)庫變成了科學(xué)，層次性數(shù)據(jù)廣泛存在

-層次結(jié)構(gòu)復(fù)雜度在于訪問樹的方式

樹狀結(jié)構(gòu)的保存只要一張表- 深度、所有權(quán)、多重父節(jié)點

---

1/鄰接模型 ：id + pid(parent id)即可，遞歸的

2/物化路徑模型：每個節(jié)點和樹中的位置作為數(shù)據(jù)，1.2 代表節(jié)點， 1.2.3的父節(jié)點為1.2，比起鄰接模型含有兄弟節(jié)點的排序。（家譜）

3/嵌套集合模型:節(jié)點是左右的值，他包含了所有介于左右值之間的節(jié)點

都是滿足三范式的！

自頂向上的查詢

自底向上的查詢

聚合來自樹的值

6.并發(fā)和大數(shù)據(jù)量

負載增加未必是造成性能的原因，只不過是使得性能問題暴露出來了而已。

設(shè)計-反范式模式

1NF一個字段只當作一個值來使用（身份證號碼

2NF一條記錄可以被唯一組建區(qū)分

3NF字段和字段間不存在函數(shù)依賴（不能互相推倒，一個字段的全部，不能拆分字段，否則不滿足第一范式。）

打破三范式，提高數(shù)據(jù)庫性能，降低表連接的數(shù)量，大幅度提升查詢效率，降低查詢優(yōu)化器的優(yōu)化難度。

打破范式是引入可控制的冗余！

規(guī)范弱化，降低靈活性；需要更新時手動添加額外的操作，多處更新冗余；加速查詢效率，讓更新變慢。

逆規(guī)范化的方法：

一對一關(guān)系。部分參與的1…1對0…1可以進行合并，全參與++

1:*關(guān)系。在多的關(guān)系中加一列，觸發(fā)器自動更新。

1:*關(guān)系。復(fù)制外鍵列來減少連接

復(fù)制多對多關(guān)系中的列

引入重復(fù)組。電話/地址多個，一組地址-一組電話號碼/重復(fù)組打包放在主表中，重復(fù)組的絕對數(shù)量是一致的，該數(shù)量是靜態(tài)的，且不是很大。

創(chuàng)建額外表extra tables，不能做實時計算，但是太好用了。后續(xù)維護太難了，而且更新開銷大。體虛表？

分區(qū)

并發(fā)與大數(shù)據(jù)量處理的基本邏輯

-并發(fā)讀取數(shù)據(jù)

where中使用有索引的列和無索引的列性能差異很大 5000次/分鐘。有索引-快速查詢。

排隊，數(shù)據(jù)庫引擎能否快速服務(wù)，首先是數(shù)據(jù)庫引擎性能（閥值問題）；數(shù)據(jù)服務(wù)的請求復(fù)雜度（用戶）。快查詢會被慢查詢拖累。–整體吞吐量

-并發(fā)修改數(shù)據(jù)

加鎖

鎖的粒度。行級鎖(細粒度)，不同進程可以修改同一張表的不同行；表級鎖，一次只能修改一張表。選擇更細粒度的鎖，支持更多并發(fā)數(shù)量，處理器更多工作，提高資源利用率。

系統(tǒng)資源要為業(yè)務(wù)過程服務(wù)！

*不要隨便使用表級鎖

*盡量縮短加鎖時間，釋放鎖的資源。快速會被慢速拖累。delete沒有where子句，用truncate(?)———必須頻繁提交，可以承擔額外的失敗，但是每個邏輯單元完成后提交會增加大量開銷。

索引維護！

語句性能高，程序性能不一定高

• 避免SQL語句上的循環(huán)（SQL本身就是一個循環(huán)！）
• 減少IO交互次數(shù)，一個SQL完成所有工作
• 跨機器交互次數(shù)越少越好
• 把所有不重要不必要的SQL語句放在邏輯工作單元之外

可伸縮性。行級鎖能產(chǎn)生更佳的吞吐量。行級鎖大都性能曲線很快達到極限。

資源競爭

插入與競爭。需要串形化處理。競爭主要發(fā)生在表和索引。數(shù)據(jù)庫層面的競，爭會引起進程的競爭。當然可以降低鎖的粒度，避免對鎖的等待，快速提交事務(wù)，跟新可能會慢一點。再業(yè)務(wù)滿足情況下，取最小的事務(wù)。

DBA解決方案。無關(guān)業(yè)務(wù)邏輯，針對數(shù)據(jù)容器的改變。解決插入問題-事務(wù)空間配置，可用列表的配置

架構(gòu)解決問題/設(shè)計問題，在insert上效果不好

• 分區(qū)
• 逆序索引
• IOT，基本表和索引融合，降低競爭數(shù)量

開發(fā)解決方案

限制最高session數(shù)

不使用系統(tǒng)生成鍵，連續(xù)值只在范圍查詢中得到使用，ID本身和業(yè)務(wù)無關(guān)時，就不使用連續(xù)值，使用隨機數(shù)來進行。

主鍵索引是案例的瓶頸！使用生成數(shù)字。限制并發(fā)連接的session使得系統(tǒng)成為最佳的性能。

-大數(shù)據(jù)量

操作對數(shù)據(jù)量增加的敏感程度？

無影響

主鍵檢索等單一查詢，B樹索引

線性增長

返回記錄數(shù)量和查詢毫無關(guān)系

SQL操作的數(shù)據(jù)和最后返回的結(jié)果無關(guān)（聚合函數(shù)）

增加缺省條件-時間范圍，設(shè)定上限，這依賴于業(yè)務(wù)需求。

非線性

排序性能影響非線性

間歇性性能降低，看內(nèi)存大小

-大數(shù)據(jù)量的一些基本邏輯

綜合的考量

需求之外加上限制條件，作為一個普遍的規(guī)則

1.數(shù)據(jù)量增加對性能的預(yù)估

隱藏在查詢背后對數(shù)據(jù)量的高敏感性

如max（）對數(shù)據(jù)量的高敏感度，而直接引起子查詢性能緩慢降低，必須使用非關(guān)聯(lián)子查詢（in只執(zhí)行一次），關(guān)聯(lián)嵌套子查詢（exist每次執(zhí)行，指數(shù)增加！）。

2.排序的影響

最大問題是排序的數(shù)據(jù)是否都在內(nèi)存中，都在內(nèi)存中的話還好，如果在硬盤中那么很耗費資源。JOIN，order by的順序需要考慮

字節(jié)數(shù)量而不是記錄數(shù)量

排序的總數(shù)據(jù)量（非關(guān)系操作不會被優(yōu)化，會切一刀，在非關(guān)系優(yōu)化前后分開進行）

Join要被延后到最后階段，對盡量少的數(shù)據(jù)進行排序//降低中間結(jié)果集的大小！

消除關(guān)聯(lián)子查詢，外層條件夠好才用這個關(guān)聯(lián)子查詢，每次被調(diào)用，分散調(diào)度會導(dǎo)致性能障礙。

減少嵌套的子查詢

同時看看能不能將where中的變?yōu)閒rom中的視圖

3.通過分區(qū)提高性能（數(shù)據(jù)庫的設(shè)計具有時效性）

小數(shù)據(jù)量有用的索引可能會越來越低效。條件變差了搜索比例增高。

全表遍歷可能會不那么慢，需要檢索大量數(shù)據(jù)時，效率會更高。當符合條件的記錄達到一定閥值。

分區(qū)中大掃蕩數(shù)據(jù)提高效率。

分區(qū)鍵需要均衡性

范圍查詢，單邊范圍查詢，對索引分區(qū)不會帶來很大好處。多個分區(qū)/使用索引太慢了。單邊變成區(qū)間

insert插入需要維護索引。update需要維護更新上的索引，但一定含有where語句，面臨加鎖死鎖的可能性，需要存儲元數(shù)據(jù)來回滾。delete包含insert和update所有缺點。把DELETE變成UPDATE！！

使用標志位

構(gòu)建刪除的時間戳GOOD

無可奈何？讀寫分離階段！數(shù)據(jù)倉庫階段

高性能數(shù)據(jù)庫開發(fā)原則-為性能而設(shè)計

關(guān)系理論

縮小中間結(jié)果集，未必包含全部的字段。

有限數(shù)據(jù)的查詢中，記錄的存放順序?qū)Σ樵冇杏绊憽?/p>

規(guī)范化

真正的風(fēng)險是數(shù)據(jù)的不一致性，犯錯的概率，手工保持一致性。迭代更新重構(gòu)的困難。

保護工作！

有值、空值、無值

空值意味著關(guān)系模型存在嚴重的問題

空值對程序邏輯是很危險的

少用Boolean類型

提高信息密度

但是要保證原子性1NF

不能為了數(shù)據(jù)而數(shù)據(jù)

子類型SubType

互斥模型-唯一身份

多繼承模型- 多個子表

約束應(yīng)明確說明

數(shù)據(jù)中的隱含約束是一種不良設(shè)計，可能會導(dǎo)致運行錯誤。

健壯性、可讀性、可擴展性

數(shù)據(jù)的語義屬于DBMS！！！

過于靈活的危險

成本急劇上升，性能令人失望

如何處理歷史數(shù)據(jù)

某一時刻的商品價格，商品ID，生效時間，價格

獲取當前價格很笨拙！

保存價格有效的終止時間？比較當前和終止時間的關(guān)系。不符合業(yè)務(wù)要求。雙十一—價格變化的生效時間，自動改變，價格表中保存未來的價格，并不是由終止時間產(chǎn)生的。

保存兩者？終止時間和生效時間必須連續(xù)！

當前價格表，歷史價格表？維護太難了，未來的價格，定時觸發(fā)器，開始寫入當前價格。雙十一-批處理過程。

處理流程

批處理

實時交易-同步處理//必須及早發(fā)現(xiàn)問題

數(shù)據(jù)模型必須考慮數(shù)據(jù)處理流程

數(shù)據(jù)集中化

分布式數(shù)據(jù)系統(tǒng)，復(fù)雜度++，健壯性–，管理投入++，

離數(shù)據(jù)越近，訪問速度越快

系統(tǒng)復(fù)雜性

數(shù)據(jù)庫的錯誤很多- 硬件故障(磁盤故障)、錯誤操作…

數(shù)據(jù)恢復(fù)往往是RD和DBA爭論焦點

DBA，即便確保數(shù)據(jù)庫本身工作正常，依然無法了解數(shù)據(jù)是否正確

RD，在數(shù)據(jù)庫恢復(fù)后進行所有的功能性的檢查

---

錯誤的設(shè)計是導(dǎo)致災(zāi)難性后果的源泉

? 解決設(shè)計問題會浪費驚人的精力和智慧

? 性能問題非常普遍

? 打著“改善性能”的旗號進行非規(guī)范化處理，常常使性能問題變得更糟

? 成果的數(shù)據(jù)建模和數(shù)據(jù)操作應(yīng)嚴格遵循基本的設(shè)計原則。

---

數(shù)據(jù)庫本身就是一個大尺度問題。

圣誕節(jié)零點？時區(qū)？？UTC

性能，監(jiān)控，審計，錯誤處理–大尺度，大復(fù)雜度

解決方案沒有對錯，只有結(jié)果好壞

Q：SQL語句很慢，怎么辦？

1.分析問題
如何慢，怎么慢的。
偶爾？一直？過去快現(xiàn)在慢？
2.結(jié)合幾種優(yōu)化對應(yīng)的具體場景
索引：有沒有使用？數(shù)據(jù)量增大了，索引可能起副作用。
SQL語句優(yōu)化：過濾條件？連接？要不要讀寫分離？
并發(fā)訪問？
3.整體評估

總結(jié)

以上是生活随笔為你收集整理的数据库开发技术的课程记录的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。