建站
咨詢(xún)
售后
建站咨詢(xún)
新聞中心
?因?yàn)橐淮笤缬袀€(gè)合作伙伴前來(lái)交流，所以昨天的文章實(shí)際上是匆匆發(fā)出來(lái)的，并沒(méi)有完整的表達(dá)出我對(duì)這個(gè)問(wèn)題的看法。今天在外面出差，本來(lái)和客戶(hù)約好上午見(jiàn)面，因?yàn)榕R時(shí)的安排問(wèn)題，又改到下午了，所以早上有比較充裕的時(shí)間來(lái)寫(xiě)一寫(xiě)昨天想表達(dá)的另外一層意思。
創(chuàng)新互聯(lián)建站專(zhuān)注于拜城企業(yè)網(wǎng)站建設(shè),成都響應(yīng)式網(wǎng)站建設(shè)公司,商城網(wǎng)站定制開(kāi)發(fā)。拜城網(wǎng)站建設(shè)公司,為拜城等地區(qū)提供建站服務(wù)。全流程按需開(kāi)發(fā)網(wǎng)站，專(zhuān)業(yè)設(shè)計(jì)，全程項(xiàng)目跟蹤，創(chuàng)新互聯(lián)建站專(zhuān)業(yè)和態(tài)度為您提供的服務(wù)
表連接的性能關(guān)系到絕大多數(shù)管理信息系統(tǒng)的性能問(wèn)題，而最常用的表連接方式就是NESTED LOOP和HASH JOIN。當(dāng)HASH JOIN還不成熟的時(shí)候，NESTED LOOP是主打，不過(guò)對(duì)于一些左表返回?cái)?shù)據(jù)較多或者說(shuō)找不到一張返回?cái)?shù)據(jù)量較少（比如小于幾百）的左表的情況下，SQL的性能是很差的。HASH JOIN讓一些大查詢(xún)的性能得到了有效的優(yōu)化。不過(guò)HASH JOIN也不是任何時(shí)候都有效的，如果原本使用NESTED LOOP的連接被錯(cuò)誤的選擇為HASH JOIN，會(huì)帶來(lái)巨大的不必要的掃描開(kāi)銷(xiāo)，也會(huì)影響SQL的執(zhí)行時(shí)間。因此選擇適當(dāng)?shù)谋磉B接方式對(duì)于SQL性能來(lái)說(shuō)十分關(guān)鍵。
昨天在我的測(cè)試中存在問(wèn)題的執(zhí)行計(jì)劃，實(shí)際上都是企業(yè)的信息系統(tǒng)中很常見(jiàn)的SQL產(chǎn)生的，這些SQL在Oracle中表現(xiàn)都是很好的，而當(dāng)使用某些開(kāi)源數(shù)據(jù)庫(kù)或者國(guó)產(chǎn)數(shù)據(jù)庫(kù)時(shí)才會(huì)出現(xiàn)問(wèn)題，這也反映出我們的國(guó)產(chǎn)數(shù)據(jù)庫(kù)在優(yōu)化器上與Oracle的差距。優(yōu)化常見(jiàn)表連接的執(zhí)行計(jì)劃的能力，實(shí)際上應(yīng)該作為國(guó)產(chǎn)數(shù)據(jù)庫(kù)十分重要的一項(xiàng)工作來(lái)做。
SQL解析過(guò)程中都會(huì)有SQL REWRITE這個(gè)階段，實(shí)際上我們遇到的很多SQL的執(zhí)行計(jì)劃有問(wèn)題，都是在這個(gè)階段沒(méi)能改寫(xiě)出更優(yōu)的SQL來(lái)，所以后續(xù)的執(zhí)行計(jì)劃生成就會(huì)陷入到優(yōu)化器的缺陷中了。優(yōu)化器的改進(jìn)是個(gè)十分艱苦的過(guò)程，其難度巨大，PG數(shù)據(jù)庫(kù)這些年雖然版本迭代很快，但是優(yōu)化器中的幾個(gè)頑疾一直沒(méi)有解決掉（昨天我舉的例子中的執(zhí)行計(jì)劃存在問(wèn)題的地方，都是PG優(yōu)化器由來(lái)已久的頑疾），這也充分說(shuō)明了優(yōu)化器核心提升的難度。
不過(guò)SQL REWRITE這個(gè)階段與優(yōu)化器的核心之間相對(duì)獨(dú)立（當(dāng)然其中關(guān)聯(lián)也十分緊密），因此優(yōu)化SQL REWRITE階段的能力可以作為數(shù)據(jù)庫(kù)廠商優(yōu)先發(fā)力的地方，能夠把一個(gè)優(yōu)化器較難處理的SQL改寫(xiě)出一個(gè)比較容易處理的SQL，那么某些老大難的問(wèn)題就不需要?jiǎng)觾?yōu)化器的核心，也能夠解決問(wèn)題了。
一年期我寫(xiě)過(guò)一篇文章《從兩個(gè)小例子看我們的差距》，其中一個(gè)是我們以前討論過(guò)的一個(gè)ORACLE CBO優(yōu)化器的例子。在一份100053 trace里，我看到了一個(gè)十分奇怪的現(xiàn)象，SQL語(yǔ)句被莫名其妙的做了一次謂詞內(nèi)推（FPD）的轉(zhuǎn)換，在SQL上莫名其妙的增加了一個(gè)基于函數(shù)索引的謂詞斷語(yǔ)。剛開(kāi)始的時(shí)候，我認(rèn)為這種SQL REWRITE后，甚至語(yǔ)義都變了，SQL的執(zhí)行結(jié)果都有可能不對(duì)了，Oracle CBO為什么要做這樣的FPD呢。后來(lái)經(jīng)過(guò)分析發(fā)現(xiàn)SQL有個(gè)WHERE ADATE=’20210102 122103’ 這樣的條件，不過(guò)ADATE上并無(wú)索引，不過(guò)存在一個(gè)substr(ADATE,1,8)索引。按理說(shuō)這個(gè)索引不會(huì)被使用，不過(guò)這個(gè)場(chǎng)景下，使用函數(shù)索引能夠有效地提高SQL的效率。而在Oracle的核心優(yōu)化器中增加這方面的能力將會(huì)是一個(gè)大改動(dòng)，于是Oracle巧妙的添加了一條FPD規(guī)則，對(duì)此類(lèi)SQL通過(guò)規(guī)則進(jìn)行一次簡(jiǎn)單的改寫(xiě)，優(yōu)化器對(duì)于處理此類(lèi)Sql的性能就大大提高了。
最近這一年里，做了大量的數(shù)據(jù)庫(kù)國(guó)產(chǎn)化替代相關(guān)研究與測(cè)試工作，我發(fā)現(xiàn)現(xiàn)在絕大多數(shù)國(guó)產(chǎn)數(shù)據(jù)庫(kù)都在高唱秒殺一切的性能，優(yōu)秀的TPC-C/TPC-H指標(biāo)，不過(guò)我們的用戶(hù)的實(shí)際體驗(yàn)是應(yīng)用從Oracle遷移下來(lái)以后大量的SQL執(zhí)行性能下降數(shù)十倍甚至數(shù)百倍?；谶@些應(yīng)用體驗(yàn)，我覺(jué)得我們的國(guó)產(chǎn)數(shù)據(jù)庫(kù)廠商真的需要在這些“小地方”多下點(diǎn)功夫，能夠讓用戶(hù)用得更爽。因?yàn)槲覀冇脩?hù)的應(yīng)用場(chǎng)景中，超過(guò)99%的場(chǎng)景是普通的管理信息系統(tǒng)，而不是超高并發(fā)，超高交易量的TPMC場(chǎng)景。能夠踏踏實(shí)實(shí)把用戶(hù)最需要的日常問(wèn)題都解決好了，用戶(hù)的應(yīng)用開(kāi)發(fā)，應(yīng)用遷移成本都降低了，自然使用你的產(chǎn)品的用戶(hù)就會(huì)越來(lái)越多。
文章標(biāo)題：客戶(hù)應(yīng)用中遇到問(wèn)題的地方就是國(guó)產(chǎn)數(shù)據(jù)庫(kù)的發(fā)力點(diǎn)
當(dāng)前地址：http://m.fisionsoft.com.cn/article/dhpescd.html
