1樓：
資料庫系統太複雜，需要團隊協作才可能寫出來，最難的是專案的工程化，把複雜問題簡化為乙個個小問題，完成後再整合起來，保持系統不處於失控狀態。
最精華的地方在於如何定義執行計畫，這是優化器的輸出，也是執行器的輸入。乙個反面的例子是MySQL, 它的定義不太好，導致優化器和執行器的改造/提公升空間非常有限。執行計畫的定義形式，不但決定了執行器的執行方法，也決定了優化器的提公升空間。
不同的產品其實現途徑有所差別， 多分幾步，少分幾步，感覺並不重要。
2樓：
我個人覺得，這個問題不是那麼專業，工業界和學術界，應該都不會說資料庫最難的地方在哪，最精華的地方在哪。
資料庫，按照定義，是按照一定資料模型組織的、長期儲存在計算機中、可被多個使用者共享的資料聚集。
資料庫管理系統，按照定義，是一套建立和管理資料庫的軟體，介於應用程式和作業系統之間，具有資料定義、資料操縱、資料庫執行管理、資料庫的建立和維護等功能。
從這兩個定義來看，題主應該問的是資料庫管理系統。
就以抽象資料型別作為最原始的起點來推導吧。學過資料結構的人，想必對抽象資料型別十分熟悉了。抽象資料型別，包括三個組成部分：資料型別、資料間的關係、操作方法。
沒錯，看看資料庫管理系統的前兩個功能：資料定義、資料操縱，是不是感覺到就是乙個抽象資料型別了？
如果題主問的是資料庫，那麼就存在乙個資料建模的問題，即資料型別是什麼，或者資料定義是什麼？為了解決這個問題，就必須在數學上解決資料建模。這是第乙個問題。
雖然在傳統的資料庫中，廣泛地採用E-R模型，但是，對於半結構化、非結構化、異構的資料，是沒有辦法解決的。所以，產生了眾多態別的NoSQL資料庫。資料的建模，必須保證資料操縱。
對於關係模型，由於關係代數，所以有非常棒的通用的關係運算規則。但是，對於非關係型資料模型，很難找到一種通用模型。學術界借用本體，作為資料模型，不過似乎運算規則沒有進展。
在工業界，轉化為某種常規的資料模型，然後在應用層進行處理，但是，不具備通用性。這是第乙個難題。
現在假設這個難題解決了，就採用關係模型吧。那麼接下來就是資料的儲存和檢索問題。由於資料量大，無法放在記憶體中（記憶體資料庫是另一回事，流式處理後，這個資料就不再用了，或者快取），所以必須放在外存中。
但是，磁碟是塊裝置。所以，如何存放資料。資料結構的教材，後面有N種方法。
這就是儲存引擎的問題。設計乙個儲存引擎，又是乙個難題。對於常規的關聯式資料庫，還好辦一些。
比如B樹。但是，對於時態、空間資料，也是問題頗多。
接下來，假設儲存引擎解決了，比如採用B+樹。
3樓：
如果是給企業做的話，應該是在將來業務內容尚不明確的時候（甲方的需求會變得一塌糊塗），建立乙個隨著產品迭代還可以保持基本架構穩定的資料庫結構。如果這一點做不到，基本產品要黃或者潛力有限。
這個沒法分步驟，只能靠經驗。
之後就是索引優化了。。
4樓：
要說『資料庫』最難的地方，應該是『數』字吧，筆畫數最多……
資料庫是一種很複雜的應用系統。說資料庫系統的複雜，是因為資料庫系統自身在作業系統之上又實現了一把任務排程、記憶體管理和儲存管理。也就是說資料庫系統自身帶乙個作業系統。
這個作業系統用來排程執行緒執行查詢、檢查事務一致性；負責吃光它能使用的全部物理記憶體並和磁碟進行熱資料的交換；還得在現有作業系統的檔案系統上維護自己的一組資料庫檔案。
從大的方面說，寫這麼乙個東東基本上就是乙個簡單的作業系統的複雜度了。我覺得這部分才是最難的。這個文章算是個佐證吧：難圓滿的SQL Server 2017Linux夢
5樓：申礫
測試，如何保證寫出來的資料庫是對的
如何保證架構簡單以及可擴充套件
如果是乙個分布式資料庫的話，要考慮從上到下各個元件之間如何協調、如何構架乙個穩定的系統，總有一些場景是你想不到的
6樓：silence
都難，每一塊都可以深入挖掘。查詢直譯器，查詢優化器，B+樹，日誌，鎖機制，事務併發，資料壓縮儲存，跨平台，Cache等等
7樓：龐子勇
難在隨著業務量逐漸增大，系統併發要求越來越高，乙個個系統瓶頸都逐漸被打破。確又要保證資料庫系統效能優越，功能穩定。這時對系統挑戰是比較大的。
8樓：
資料庫三大件：查詢優化/索引設計/快取，其實都不難，難就難在你要做到哪個水平嘍。x水平，大約10%的人具備這個能力，y水平；大約5%，市面上大部分商業資料庫就是這個水平；z水平，三大件必須都是業界頂尖，大約0.
5%的人具備這個能力，但是這些人可能沒從事資料庫，自己對號入座吧
9樓：鏟屎官王發財
此答案是我做oracle dba時寫的：最難的，是資料恢復。估計不會有再難的了。
此答案是我做mysql和postgresql dba寫的：
整個資料庫，其實就是乙個鎖機制。
事務處理核心是鎖機制。
高可用核心是鎖機制。
記憶體優化核心還是latch。
其實現在大部分資料庫的功能大同小異，基本就是你有的東西我也要有，我現在沒有以後也會有。但在鎖機制上，好多設計理念都不一樣。能設計mysql、oracle和postgres的，都是業界大牛，誰也不比誰差，能讓他們有分歧的問題，才是難題。
10樓：周德強
我覺得資料庫最難的地方還在於在設計之初，就考慮到業務擴充套件的情況。
比如使用者暴漲，新業務追加，新邏輯追加等等。
如果設計之初就考慮到了這些，那麼在優化效能的時候，就可以有目的的取捨了。
11樓：pretty kernel
我認為查詢優化和儲存引擎比較難.
資料庫最精華的部分是事務處理. 這是各個資料庫最大的區別之一.
你需要一本 《事務處理》, 大神寫的.
12樓：朱沚汀
我覺得就是transaction manager. 基本上ACID property主要就是靠這塊保持的。系統的through put也和transaction 處理的效率有關。
怎麼實現乙個簡單的資料庫系統？
劉浩浩 這種類似的東西，最重要的是一定要看過已經有的開源實現的原始碼，從頭到尾搞懂別人的思路。我自己寫過基於UDP的可靠協議，用go寫的，開始寫之前看了各種他人的原始碼和一些已有的實現，感覺受益匪淺，後面寫起來感覺前期的調研是很重要的。因此建議，先看懂乙個完整的實現，不需要mysql這樣的大東西，看...
如何修改乙個已存在的資料庫名稱？
愛可生 被取消的命令MySQL 之前提供了乙個 rename database db old to db new 的命令來直接對資料庫改名，可能由於實現的功能不完備 比如，這條命令可能是乙個超大的事務，或者是由於之前的表很多還是 MyISAM 等 後來的版本直接取消了這條命令。更改資料庫名大致上有以...
乙個優秀的關係型資料庫儲存引擎應該具備哪些功能, 達到哪些指標
肖堂 數蠶 資料庫儲存引擎是資料庫的最基礎的部分，是資料庫的各種功能的實現的載體，它的功能包含儲存結構 含索引結構 事務功能，快取機制，監控或分析機制。其中儲存結構和索引結構是最基礎的功能，用於保證資料的完整性，高效性和查詢特性。事務功能應該滿足基礎的事務的基本級別，至少支援最高端別。支援回滾。快取...