MySQL常見(jiàn)的存儲(chǔ)引擎InnoDB、MyISAM有何區(qū)別?
41、增加B+樹(shù)的路數(shù)可以降低樹(shù)的高度,那么無(wú)限增加樹(shù)的路數(shù)是不是可以有最優(yōu)的查找效率?
不可以。因?yàn)檫@樣會(huì)形成一個(gè)有序數(shù)組,文件系統(tǒng)和數(shù)據(jù)庫(kù)的索引都是存在硬盤(pán)上的,并且如果數(shù)據(jù)量大的話(huà),不一定能一次性加載到內(nèi)存中。有序數(shù)組沒(méi)法一次性加載進(jìn)內(nèi)存,這時(shí)候B+樹(shù)的多路存儲(chǔ)威力就出來(lái)了,可以每次加載B+樹(shù)的一個(gè)結(jié)點(diǎn),然后一步步往下找,
42、說(shuō)一下數(shù)據(jù)庫(kù)表鎖和行鎖吧表鎖
不會(huì)出現(xiàn)死鎖,發(fā)生鎖沖突幾率高,并發(fā)低。
MyISAM在執(zhí)行查詢(xún)語(yǔ)句(select)前,會(huì)自動(dòng)給涉及的所有表加讀鎖,在執(zhí)行增刪改操作前,會(huì)自動(dòng)給涉及的表加寫(xiě)鎖。
MySQL的表級(jí)鎖有兩種模式:表共享讀鎖和表獨(dú)占寫(xiě)鎖。
讀鎖會(huì)阻塞寫(xiě),寫(xiě)鎖會(huì)阻塞讀和寫(xiě)
對(duì)MyISAM表的讀操作,不會(huì)阻塞其它進(jìn)程對(duì)同一表的讀請(qǐng)求,但會(huì)阻塞對(duì)同一表的寫(xiě)請(qǐng)求。只有當(dāng)讀鎖釋放后,才會(huì)執(zhí)行其它進(jìn)程的寫(xiě)操作。對(duì)MyISAM表的寫(xiě)操作,會(huì)阻塞其它進(jìn)程對(duì)同一表的讀和寫(xiě)操作,只有當(dāng)寫(xiě)鎖釋放后,才會(huì)執(zhí)行其它進(jìn)程的讀寫(xiě)操作。
MyISAM不適合做寫(xiě)為主表的引擎,因?yàn)閷?xiě)鎖后,其它線(xiàn)程不能做任何操作,大量的更新會(huì)使查詢(xún)很難得到鎖,從而造成永遠(yuǎn)阻塞。
行鎖
會(huì)出現(xiàn)死鎖,發(fā)生鎖沖突幾率低,并發(fā)高。
在MySQL的InnoDB引擎支持行鎖,與Oracle不同,MySQL的行鎖是通過(guò)索引加載的,也就是說(shuō),行鎖是加在索引響應(yīng)的行上的,要是對(duì)應(yīng)的SQL語(yǔ)句沒(méi)有走索引,則會(huì)全表掃描,行鎖則無(wú)法實(shí)現(xiàn),取而代之的是表鎖,此時(shí)其它事務(wù)無(wú)法對(duì)當(dāng)前表進(jìn)行更新或插入操作。
行鎖的實(shí)現(xiàn)需要注意:
行鎖必須有索引才能實(shí)現(xiàn),否則會(huì)自動(dòng)鎖全表,那么就不是行鎖了。兩個(gè)事務(wù)不能鎖同一個(gè)索引。insert,delete,update在事務(wù)中都會(huì)自動(dòng)默認(rèn)加上排它鎖。
行鎖的適用場(chǎng)景:
A用戶(hù)消費(fèi),service層先查詢(xún)?cè)撚脩?hù)的賬戶(hù)余額,若余額足夠,則進(jìn)行后續(xù)的扣款操作;這種情況查詢(xún)的時(shí)候應(yīng)該對(duì)該記錄進(jìn)行加鎖。
否則,B用戶(hù)在A用戶(hù)查詢(xún)后消費(fèi)前先一步將A用戶(hù)賬號(hào)上的錢(qián)轉(zhuǎn)走,而此時(shí)A用戶(hù)已經(jīng)進(jìn)行了用戶(hù)余額是否足夠的判斷,則可能會(huì)出現(xiàn)余額已經(jīng)不足但卻扣款成功的情況。
為了避免此情況,需要在A用戶(hù)操作該記錄的時(shí)候進(jìn)行for update加鎖
43、SQL語(yǔ)法中內(nèi)連接、自連接、外連接(左、右、全)、交叉連接的區(qū)別分別是什么?
內(nèi)連接:只有兩個(gè)元素表相匹配的才能在結(jié)果集中顯示。
外連接:左外連接: 左邊為驅(qū)動(dòng)表,驅(qū)動(dòng)表的數(shù)據(jù)全部顯示,匹配表的不匹配的不會(huì)顯示。
右外連接:右邊為驅(qū)動(dòng)表,驅(qū)動(dòng)表的數(shù)據(jù)全部顯示,匹配表的不匹配的不會(huì)顯示。全外連接:連接的表中不匹配的數(shù)據(jù)全部會(huì)顯示出來(lái)。
交叉連接:笛卡爾效應(yīng),顯示的結(jié)果是鏈接表數(shù)的乘積。
44、你知道哪些數(shù)據(jù)庫(kù)結(jié)構(gòu)優(yōu)化的手段?
范式優(yōu)化:比如消除冗余(節(jié)省空間。。)反范式優(yōu)化:比如適當(dāng)加冗余等(減少join)限定數(shù)據(jù)的范圍:務(wù)必禁止不帶任何限制數(shù)據(jù)范圍條件的查詢(xún)語(yǔ)句。比如:我們當(dāng)用戶(hù)在查詢(xún)訂單歷史的時(shí)候,我們可以控制在一個(gè)月的范圍內(nèi)。讀/寫(xiě)分離:經(jīng)典的數(shù)據(jù)庫(kù)拆分方案,主庫(kù)負(fù)責(zé)寫(xiě),從庫(kù)負(fù)責(zé)讀;拆分表:分區(qū)將數(shù)據(jù)在物理上分隔開(kāi),不同分區(qū)的數(shù)據(jù)可以制定保存在處于不同磁盤(pán)上的數(shù)據(jù)文件里。這樣,當(dāng)對(duì)這個(gè)表進(jìn)行查詢(xún)時(shí),只需要在表分區(qū)中進(jìn)行掃描,而不必進(jìn)行全表掃描,明顯縮短了查詢(xún)時(shí)間,另外處于不同磁盤(pán)的分區(qū)也將對(duì)這個(gè)表的數(shù)據(jù)傳輸分散在不同的磁盤(pán)I/O,一個(gè)精心設(shè)置的分區(qū)可以將數(shù)據(jù)傳輸對(duì)磁盤(pán)I/O競(jìng)爭(zhēng)均勻地分散開(kāi)。對(duì)數(shù)據(jù)量大的時(shí)時(shí)表可采取此方法?砂丛伦詣(dòng)建表分區(qū)。
45、數(shù)據(jù)庫(kù)優(yōu)化中有一個(gè)比較常用的手段就是把數(shù)據(jù)表進(jìn)行拆分,關(guān)于拆分?jǐn)?shù)據(jù)表你了解哪些?
拆分其實(shí)又分垂直拆分和水平拆分
案例:簡(jiǎn)單購(gòu)物系統(tǒng)暫設(shè)涉及如下表:
1.產(chǎn)品表(數(shù)據(jù)量10w,穩(wěn)定)
2.訂單表(數(shù)據(jù)量200w,且有增長(zhǎng)趨勢(shì))
3.用戶(hù)表 (數(shù)據(jù)量100w,且有增長(zhǎng)趨勢(shì))
以 MySQL 為例講述下水平拆分和垂直拆分,MySQL能容忍的數(shù)量級(jí)在百萬(wàn)靜態(tài)數(shù)據(jù)可以到千萬(wàn)
垂直拆分
解決問(wèn)題:表與表之間的io競(jìng)爭(zhēng)
不解決問(wèn)題:?jiǎn)伪碇袛?shù)據(jù)量增長(zhǎng)出現(xiàn)的壓力
方案:把產(chǎn)品表和用戶(hù)表放到一個(gè)server上 訂單表單獨(dú)放到一個(gè)server上
水平拆分
解決問(wèn)題:?jiǎn)伪碇袛?shù)據(jù)量增長(zhǎng)出現(xiàn)的壓力
不解決問(wèn)題:表與表之間的io爭(zhēng)奪
方案:用戶(hù)表 通過(guò)性別拆分為男用戶(hù)表和女用戶(hù)表,訂單表 通過(guò)已完成和完成中拆分為已完成訂單和未完成訂單,產(chǎn)品表 未完成訂單放一個(gè)server上,已完成訂單表盒男用戶(hù)表放一個(gè)server上,女用戶(hù)表放一個(gè)server上(女的愛(ài)購(gòu)物 哈哈)。
46、為什么MySQL索引要使用B+樹(shù),而不是B樹(shù)或者紅黑樹(shù)?
我們?cè)贛ySQL中的數(shù)據(jù)一般是放在磁盤(pán)中的,讀取數(shù)據(jù)的時(shí)候肯定會(huì)有訪問(wèn)磁盤(pán)的操作,磁盤(pán)中有兩個(gè)機(jī)械運(yùn)動(dòng)的部分,分別是盤(pán)片旋轉(zhuǎn)和磁臂移動(dòng)。盤(pán)片旋轉(zhuǎn)就是我們市面上所提到的多少轉(zhuǎn)每分鐘,而磁盤(pán)移動(dòng)則是在盤(pán)片旋轉(zhuǎn)到指定位置以后,移動(dòng)磁臂后開(kāi)始進(jìn)行數(shù)據(jù)的讀寫(xiě)。那么這就存在一個(gè)定位到磁盤(pán)中的塊的過(guò)程,而定位是磁盤(pán)的存取中花費(fèi)時(shí)間比較大的一塊,畢竟機(jī)械運(yùn)動(dòng)花費(fèi)的時(shí)候要遠(yuǎn)遠(yuǎn)大于電子運(yùn)動(dòng)的時(shí)間。當(dāng)大規(guī)模數(shù)據(jù)存儲(chǔ)到磁盤(pán)中的時(shí)候,顯然定位是一個(gè)非常花費(fèi)時(shí)間的過(guò)程,但是我們可以通過(guò)B樹(shù)進(jìn)行優(yōu)化,提高磁盤(pán)讀取時(shí)定位的效率。
為什么B類(lèi)樹(shù)可以進(jìn)行優(yōu)化呢?我們可以根據(jù)B類(lèi)樹(shù)的特點(diǎn),構(gòu)造一個(gè)多階的B類(lèi)樹(shù),然后在盡量多的在結(jié)點(diǎn)上存儲(chǔ)相關(guān)的信息,保證層數(shù)(樹(shù)的高度)盡量的少,以便后面我們可以更快的找到信息,磁盤(pán)的I/O操作也少一些,而且B類(lèi)樹(shù)是平衡樹(shù),每個(gè)結(jié)點(diǎn)到葉子結(jié)點(diǎn)的高度都是相同,這也保證了每個(gè)查詢(xún)是穩(wěn)定的。
特別地:只有B-樹(shù)和B+樹(shù),這里的B-樹(shù)是叫B樹(shù),不是B減樹(shù),沒(méi)有B減樹(shù)的說(shuō)法。
47、為什么MySQL索引采用B+樹(shù)而不用hash表和B樹(shù)?
利用Hash需要把數(shù)據(jù)全部加載到內(nèi)存中,如果數(shù)據(jù)量大,是一件很消耗內(nèi)存的事,而采用B+樹(shù),是基于按照節(jié)點(diǎn)分段加載,由此減少內(nèi)存消耗。和業(yè)務(wù)場(chǎng)景有段,對(duì)于唯一查找(查找一個(gè)值),Hash確實(shí)更快,但數(shù)據(jù)庫(kù)中經(jīng)常查詢(xún)多條數(shù)據(jù),這時(shí)候由于B+數(shù)據(jù)的有序性,與葉子節(jié)點(diǎn)又有鏈表相連,他的查詢(xún)效率會(huì)比Hash快的多。b+樹(shù)的非葉子節(jié)點(diǎn)不保存數(shù)據(jù),只保存子樹(shù)的臨界值(最大或者最。酝瑯哟笮〉墓(jié)點(diǎn),b+樹(shù)相對(duì)于b樹(shù)能夠有更多的分支,使得這棵樹(shù)更加矮胖,查詢(xún)時(shí)做的IO操作次數(shù)也更少。
48、MySQL中存儲(chǔ)索引用到的數(shù)據(jù)結(jié)構(gòu)是B+樹(shù),B+樹(shù)的查詢(xún)時(shí)間跟樹(shù)的高度有關(guān),是log(n),如果用hash存儲(chǔ),那么查詢(xún)時(shí)間是O(1)。既然hash比B+樹(shù)更快,為什么MySQL用B+樹(shù)來(lái)存儲(chǔ)索引呢?
一、從內(nèi)存角度上說(shuō),數(shù)據(jù)庫(kù)中的索引一般是在磁盤(pán)上,數(shù)據(jù)量大的情況可能無(wú)法一次性裝入內(nèi)存,B+樹(shù)的設(shè)計(jì)可以允許數(shù)據(jù)分批加載。
二、從業(yè)務(wù)場(chǎng)景上說(shuō),如果只選擇一個(gè)數(shù)據(jù)那確實(shí)是hash更快,但是數(shù)據(jù)庫(kù)中經(jīng)常會(huì)選中多條,這時(shí)候由于B+樹(shù)索引有序,并且又有鏈表相連,它的查詢(xún)效率比hash就快很多了。
49、關(guān)系型數(shù)據(jù)庫(kù)的四大特性在得不到保障的情況下會(huì)怎樣?
ACID,原子性(Atomicity)、一致性(Consistency)、隔離性(Isolation)、持久性(Durability)
我們以從A賬戶(hù)轉(zhuǎn)賬50元到B賬戶(hù)為例進(jìn)行說(shuō)明一下ACID這四大特性。
原子性
原子性是指一個(gè)事務(wù)是一個(gè)不可分割的工作單位,其中的操作要么都做,要么都不做。即要么轉(zhuǎn)賬成功,要么轉(zhuǎn)賬失敗,是不存在中間的狀態(tài)!
如果無(wú)法保證原子性會(huì)怎么樣?
OK,就會(huì)出現(xiàn)數(shù)據(jù)不一致的情形,A賬戶(hù)減去50元,而B(niǎo)賬戶(hù)增加50元操作失敗。系統(tǒng)將無(wú)故丟失50元~
一致性
一致性是指事務(wù)執(zhí)行前后,數(shù)據(jù)處于一種合法的狀態(tài),這種狀態(tài)是語(yǔ)義上的而不是語(yǔ)法上的。那什么是合法的數(shù)據(jù)狀態(tài)呢?這個(gè)狀態(tài)是滿(mǎn)足預(yù)定的約束就叫做合法的狀態(tài),再通俗一點(diǎn),這狀態(tài)是由你自己來(lái)定義的。滿(mǎn)足這個(gè)狀態(tài),數(shù)據(jù)就是一致的,不滿(mǎn)足這個(gè)狀態(tài),數(shù)據(jù)就是不一致的!
如果無(wú)法保證一致性會(huì)怎么樣?例一:A賬戶(hù)有200元,轉(zhuǎn)賬300元出去,此時(shí)A賬戶(hù)余額為-100元。你自然就發(fā)現(xiàn)了此時(shí)數(shù)據(jù)是不一致的,為什么呢?因?yàn)槟愣x了一個(gè)狀態(tài),余額這列必須大于0。例二:A賬戶(hù)200元,轉(zhuǎn)賬50元給B賬戶(hù),A賬戶(hù)的錢(qián)扣了,但是B賬戶(hù)因?yàn)楦鞣N意外,余額并沒(méi)有增加。你也知道此時(shí)數(shù)據(jù)是不一致的,為什么呢?因?yàn)槟愣x了一個(gè)狀態(tài),要求A+B的余額必須不變。隔離性
隔離性是指多個(gè)事務(wù)并發(fā)執(zhí)行的時(shí)候,事務(wù)內(nèi)部的操作與其他事務(wù)是隔離的,并發(fā)執(zhí)行的各個(gè)事務(wù)之間不能互相干擾。
如果無(wú)法保證隔離性會(huì)怎么樣?
假設(shè)A賬戶(hù)有200元,B賬戶(hù)0元。A賬戶(hù)往B賬戶(hù)轉(zhuǎn)賬兩次,金額為50元,分別在兩個(gè)事務(wù)中執(zhí)行。如果無(wú)法保證隔離性,A可能就會(huì)出現(xiàn)扣款兩次的情形,而B(niǎo)只加款一次,憑空消失了50元,依然出現(xiàn)了數(shù)據(jù)不一致的情形!
持久性
根據(jù)定義,持久性是指事務(wù)一旦提交,它對(duì)數(shù)據(jù)庫(kù)的改變就應(yīng)該是永久性的。接下來(lái)的其他操作或故障不應(yīng)該對(duì)其有任何影響。
如果無(wú)法保證持久性會(huì)怎么樣?
在MySQL中,為了解決CPU和磁盤(pán)速度不一致問(wèn)題,MySQL是將磁盤(pán)上的數(shù)據(jù)加載到內(nèi)存,對(duì)內(nèi)存進(jìn)行操作,然后再回寫(xiě)磁盤(pán)。好,假設(shè)此時(shí)宕機(jī)了,在內(nèi)存中修改的數(shù)據(jù)全部丟失了,持久性就無(wú)法保證。
設(shè)想一下,系統(tǒng)提示你轉(zhuǎn)賬成功。但是你發(fā)現(xiàn)金額沒(méi)有發(fā)生任何改變,此時(shí)數(shù)據(jù)出現(xiàn)了不合法的數(shù)據(jù)狀態(tài),我們將這種狀態(tài)認(rèn)為是數(shù)據(jù)不一致的情形。
50、數(shù)據(jù)庫(kù)如何保證一致性?
分為兩個(gè)層面來(lái)說(shuō)。
從數(shù)據(jù)庫(kù)層面,數(shù)據(jù)庫(kù)通過(guò)原子性、隔離性、持久性來(lái)保證一致性。也就是說(shuō)ACID四大特性之中,C(一致性)是目的,A(原子性)、I(隔離性)、D(持久性)是手段,是為了保證一致性,數(shù)據(jù)庫(kù)提供的手段。數(shù)據(jù)庫(kù)必須要實(shí)現(xiàn)AID三大特性,才有可能實(shí)現(xiàn)一致性。例如,原子性無(wú)法保證,顯然一致性也無(wú)法保證。從應(yīng)用層面,通過(guò)代碼判斷數(shù)據(jù)庫(kù)數(shù)據(jù)是否有效,然后決定回滾還是提交數(shù)據(jù)!
51、數(shù)據(jù)庫(kù)如何保證原子性?
主要是利用 Innodb 的undo log。undo log名為回滾日志,是實(shí)現(xiàn)原子性的關(guān)鍵,當(dāng)事務(wù)回滾時(shí)能夠撤銷(xiāo)所有已經(jīng)成功執(zhí)行的 SQL語(yǔ)句,他需要記錄你要回滾的相應(yīng)日志信息。例如
當(dāng)你delete一條數(shù)據(jù)的時(shí)候,就需要記錄這條數(shù)據(jù)的信息,回滾的時(shí)候,insert這條舊數(shù)據(jù)當(dāng)你update一條數(shù)據(jù)的時(shí)候,就需要記錄之前的舊值,回滾的時(shí)候,根據(jù)舊值執(zhí)行update操作當(dāng)年insert一條數(shù)據(jù)的時(shí)候,就需要這條記錄的主鍵,回滾的時(shí)候,根據(jù)主鍵執(zhí)行delete操作
undo log記錄了這些回滾需要的信息,當(dāng)事務(wù)執(zhí)行失敗或調(diào)用了rollback,導(dǎo)致事務(wù)需要回滾,便可以利用undo log中的信息將數(shù)據(jù)回滾到修改之前的樣子。
52、數(shù)據(jù)庫(kù)如何保證持久性?
主要是利用Innodb的redo log。重寫(xiě)日志, 正如之前說(shuō)的,MySQL是先把磁盤(pán)上的數(shù)據(jù)加載到內(nèi)存中,在內(nèi)存中對(duì)數(shù)據(jù)進(jìn)行修改,再寫(xiě)回到磁盤(pán)上。如果此時(shí)突然宕機(jī),內(nèi)存中的數(shù)據(jù)就會(huì)丟失。怎么解決這個(gè)問(wèn)題?簡(jiǎn)單啊,事務(wù)提交前直接把數(shù)據(jù)寫(xiě)入磁盤(pán)就行啊。這么做有什么問(wèn)題?
只修改一個(gè)頁(yè)面里的一個(gè)字節(jié),就要將整個(gè)頁(yè)面刷入磁盤(pán),太浪費(fèi)資源了。畢竟一個(gè)頁(yè)面16kb大小,你只改其中一點(diǎn)點(diǎn)東西,就要將16kb的內(nèi)容刷入磁盤(pán),聽(tīng)著也不合理。畢竟一個(gè)事務(wù)里的SQL可能牽涉到多個(gè)數(shù)據(jù)頁(yè)的修改,而這些數(shù)據(jù)頁(yè)可能不是相鄰的,也就是屬于隨機(jī)IO。顯然操作隨機(jī)IO,速度會(huì)比較慢。
于是,決定采用redo log解決上面的問(wèn)題。當(dāng)做數(shù)據(jù)修改的時(shí)候,不僅在內(nèi)存中操作,還會(huì)在redo log中記錄這次操作。當(dāng)事務(wù)提交的時(shí)候,會(huì)將redo log日志進(jìn)行刷盤(pán)(redo log一部分在內(nèi)存中,一部分在磁盤(pán)上)。當(dāng)數(shù)據(jù)庫(kù)宕機(jī)重啟的時(shí)候,會(huì)將redo log中的內(nèi)容恢復(fù)到數(shù)據(jù)庫(kù)中,再根據(jù)undo log和binlog內(nèi)容決定回滾數(shù)據(jù)還是提交數(shù)據(jù)。
采用redo log的好處?
其實(shí)好處就是將redo log進(jìn)行刷盤(pán)比對(duì)數(shù)據(jù)頁(yè)刷盤(pán)效率高,具體表現(xiàn)如下:
redo log體積小,畢竟只記錄了哪一頁(yè)修改了啥,因此體積小,刷盤(pán)快。redo log是一直往末尾進(jìn)行追加,屬于順序IO。效率顯然比隨機(jī)IO來(lái)的快。結(jié)語(yǔ)
你學(xué)廢了嗎
---END---
你好,我是阿秀,畢業(yè)于雙非學(xué)校,校招時(shí)拿下字節(jié)跳動(dòng)SP、華為、百度等6個(gè)offer,現(xiàn)于抖音部門(mén)擔(dān)任全棧開(kāi)發(fā)工程師。
一路走來(lái),很累也很不容易,希望能幫助到更多像我一樣的普通學(xué)校的學(xué)生,我踩的坑不希望你再踩,我走過(guò)的路希望你照著走下來(lái)。公眾號(hào)后臺(tái)回復(fù)「寶貝」,送你一個(gè)寶貝!

發(fā)表評(píng)論
請(qǐng)輸入評(píng)論內(nèi)容...
請(qǐng)輸入評(píng)論/評(píng)論長(zhǎng)度6~500個(gè)字
最新活動(dòng)更多
-
3月27日立即報(bào)名>> 【工程師系列】汽車(chē)電子技術(shù)在線(xiàn)大會(huì)
-
4月30日立即下載>> 【村田汽車(chē)】汽車(chē)E/E架構(gòu)革新中,新智能座艙挑戰(zhàn)的解決方案
-
5月15-17日立即預(yù)約>> 【線(xiàn)下巡回】2025年STM32峰會(huì)
-
即日-5.15立即報(bào)名>>> 【在線(xiàn)會(huì)議】安森美Hyperlux™ ID系列引領(lǐng)iToF技術(shù)革新
-
5月15日立即下載>> 【白皮書(shū)】精確和高效地表征3000V/20A功率器件應(yīng)用指南
-
5月16日立即參評(píng) >> 【評(píng)選啟動(dòng)】維科杯·OFweek 2025(第十屆)人工智能行業(yè)年度評(píng)選
推薦專(zhuān)題
- 1 UALink規(guī)范發(fā)布:挑戰(zhàn)英偉達(dá)AI統(tǒng)治的開(kāi)始
- 2 北電數(shù)智主辦酒仙橋論壇,探索AI產(chǎn)業(yè)發(fā)展新路徑
- 3 降薪、加班、裁員三重暴擊,“AI四小龍”已折戟兩家
- 4 “AI寒武紀(jì)”爆發(fā)至今,五類(lèi)新物種登上歷史舞臺(tái)
- 5 國(guó)產(chǎn)智駕迎戰(zhàn)特斯拉FSD,AI含量差幾何?
- 6 光計(jì)算迎來(lái)商業(yè)化突破,但落地仍需時(shí)間
- 7 東陽(yáng)光:2024年扭虧、一季度凈利大增,液冷疊加具身智能打開(kāi)成長(zhǎng)空間
- 8 地平線(xiàn)自動(dòng)駕駛方案解讀
- 9 封殺AI“照騙”,“淘寶們”終于不忍了?
- 10 優(yōu)必選:營(yíng)收大增主靠小件,虧損繼續(xù)又逢關(guān)稅,能否乘機(jī)器人東風(fēng)翻身?