2025AI時(shí)代面向機(jī)器的接口語言MOQL

AI時(shí)代的變革者：面向機(jī)器的接口語言（MOQL）2025AI時(shí)代的變革者01.面向機(jī)器的接口語言（MOQL）AI對(duì)數(shù)據(jù)庫研發(fā)的變革02.通過Deepseek，分析AI對(duì)數(shù)據(jù)庫內(nèi)核開發(fā)的影響CONTENTSAI時(shí)代的變革者----面向機(jī)器的接口語言(MOQL)/01強(qiáng)大的SQL語言4強(qiáng)大的SQL語言5Text2SQL從自然語言生成SQL強(qiáng)大的SQL語言6Text2SQL從自然語言生成SQL強(qiáng)大的SQL語言7

高消耗的SQL語言強(qiáng)大的SQL語言8

高消耗的SQL語言數(shù)據(jù)讀、寫：31.88%的消耗其他、SQL：68.22%（其中SQL占30%以上）SQL與數(shù)據(jù)處理消耗資源相當(dāng)強(qiáng)大的SQL語言9MOQL：SQL執(zhí)行過程應(yīng)用端寫SQL數(shù)據(jù)庫得到SQL由SQL生成Plan執(zhí)行Plan強(qiáng)大的SQL語言10MOQL：執(zhí)行過程應(yīng)用端：Text

ToPlan數(shù)據(jù)庫得到SQLPLAN由SQL生成Plan執(zhí)行PlanSQL是為了方便應(yīng)用開發(fā)人員快速檢索、操控?cái)?shù)據(jù)。AI可以更好的讓應(yīng)用開發(fā)人員掌握數(shù)據(jù)庫。為什么不用AI代替SQL，由AI直接生成更便于數(shù)據(jù)庫執(zhí)行的“結(jié)構(gòu)”（暫定為Plan）。強(qiáng)大的SQL語言11MOQL：分階段實(shí)現(xiàn)基于開源Text2SQL模型，改造為Text2Plan階段1：整合開源Text2SQL模型，添加Plan生成功能階段2：改造開源Text2SQL模型，去除SQL階段3：優(yōu)化開源Text2Plan模型AI對(duì)數(shù)據(jù)庫研發(fā)的變革----用DS分析AI對(duì)數(shù)據(jù)庫內(nèi)核開發(fā)的影響/02AI對(duì)數(shù)據(jù)庫研發(fā)的變革13AI對(duì)數(shù)據(jù)庫研發(fā)的變革14AI對(duì)數(shù)據(jù)庫研發(fā)的變革15AI對(duì)數(shù)據(jù)庫研發(fā)的變革16操作時(shí)間（單位：毫秒）時(shí)間（單位：毫秒）Count(*)30617Count(*)29717Wherec1=‘…’51227Wherec1=‘…’51127注：以上測試，SQL執(zhí)行期間，沒有觀察到任何磁盤I/O，數(shù)據(jù)都被緩存在內(nèi)存當(dāng)中示例數(shù)據(jù)庫靜置一段時(shí)間后，查詢性能可提升百倍左右（DML10%的行后，性能又將大幅下降）AI對(duì)數(shù)據(jù)庫研發(fā)的變革17共計(jì)317個(gè)線程，線程數(shù)太多。AI對(duì)數(shù)據(jù)庫研發(fā)的變革18總結(jié)如下：上下文切換開銷內(nèi)存消耗鎖與同步開銷AI對(duì)數(shù)據(jù)庫研發(fā)的變革19每個(gè)CoreCPU使用率并不高，雖有317個(gè)線程，但多數(shù)都在sleep，這種情況下只執(zhí)行一條幾十M數(shù)據(jù)的表掃描，上下文切換的開銷，不足以導(dǎo)致近20倍的差異。Deepseek的回答，并沒有觸及問題本質(zhì)。AI對(duì)數(shù)據(jù)庫研發(fā)的變革請(qǐng)求階段處理、投遞SQL請(qǐng)求123n。。。SQL階段執(zhí)行SQL123n。。。事務(wù)階段12n。。。存儲(chǔ)階段12n。。。線程化的工作模式，新穎的開發(fā)理念：階段化SQL執(zhí)行過程分解為各個(gè)“階段”數(shù)據(jù)庫所有操作分解為“階段”資源池化每個(gè)階段，對(duì)應(yīng)完成其相關(guān)工作的模塊（也就是線程）同一階段所有線程構(gòu)成“資源池”AI對(duì)數(shù)據(jù)庫研發(fā)的變革pq_getbytesecure_readWaitEventSetWaitepoll_waitexec_simple_query或exec_bind_messageexec_execute_message可見性判斷事務(wù)處理……I/O：調(diào)用系統(tǒng)調(diào)用，等待I/O結(jié)束傳統(tǒng)的開發(fā)理念：一個(gè)進(jìn)/線程從頭到尾完成SQL所有工作AI對(duì)數(shù)據(jù)庫研發(fā)的變革22新、老開發(fā)模式的對(duì)比，Deepseek給出的回答非常好，個(gè)人感覺，至少超過80%的開發(fā)者。AI對(duì)數(shù)據(jù)庫研發(fā)的變革23對(duì)通過線程，實(shí)現(xiàn)多階段、資源池化的開發(fā)的優(yōu)、缺點(diǎn)，都總結(jié)的十分到位。大型系統(tǒng)軟件開發(fā)，Deepseek更偏向“多階段、資源池化+多線程”這種開發(fā)模式。AI對(duì)數(shù)據(jù)庫研發(fā)的變革24缺乏量化信息：延遲更高，高多少？緩存利用率較差，差多少？AI對(duì)數(shù)據(jù)庫研發(fā)的變革25

不同線程的數(shù)據(jù)同步延遲本質(zhì)是CPU同步延遲：線程1在Coren修改一個(gè)內(nèi)存變量在Corem的線程2，多久后能看到修改后的數(shù)據(jù)AI對(duì)數(shù)據(jù)庫研發(fā)的變革26

不同線程的數(shù)據(jù)同步延遲本質(zhì)是CPU同步延遲：線程1在Coren修改一個(gè)內(nèi)存變量在Corem的線程2，多久后能看到修改后的數(shù)據(jù)AI對(duì)數(shù)據(jù)庫研發(fā)的變革27

不同線程的數(shù)據(jù)同步延遲本質(zhì)是CPU同步延遲：線程1在Coren修改一個(gè)內(nèi)存變量在Corem的線程2，多久后能看到修改后的數(shù)據(jù)AI對(duì)數(shù)據(jù)庫研發(fā)的變革28

不同線程的數(shù)據(jù)同步延遲數(shù)據(jù)在不同模塊中時(shí)的延遲（以3GHz主頻為例）：L1，4~5個(gè)周期，1.33~1.67納秒L2，10~20個(gè)周期，3.3~6.7納秒L3，60~80個(gè)周期，20~26納秒跨核數(shù)據(jù)同步，180~630個(gè)周期，60~210納秒AI對(duì)數(shù)據(jù)庫研發(fā)的變革29

不同線程的數(shù)據(jù)同步延遲傳統(tǒng)開發(fā)模式，大量數(shù)據(jù)訪問可以命中L1Cache。階段化、資源池化的新型開發(fā)模式，將使本來可以在L1內(nèi)處理的數(shù)據(jù)，不得不跨核傳輸。使用perf統(tǒng)計(jì)L1cache的命中率，可以很簡單的驗(yàn)證此點(diǎn)。周期數(shù)納秒L14~51.33~1.671天L210~203.3~6.74~5天L360~8020~2615~20天跨核數(shù)據(jù)同步180~63060~21045~158天AI對(duì)數(shù)據(jù)庫研發(fā)的變革30結(jié)合示例數(shù)據(jù)庫默認(rèn)371個(gè)線程的數(shù)量，它的階段化較為徹底、階段很多。大量只需要“幾天”的操作被延長至一個(gè)多月，這是性能緩慢的根本原因。AI對(duì)數(shù)據(jù)庫研發(fā)的變革3130~120cycles，是L3自身延遲。跨核數(shù)據(jù)傳輸，需要CoreN將數(shù)據(jù)寫入L3，CoreM再從L3讀數(shù)據(jù)。延