為什么MySQL對SQL標準中很多基本用法都不支持?

一、為什么MySQL對SQL標準中很多基本用法都不支持

因為當年，在微軟.net技術(shù)棧下開發(fā)應用，用的就是sql server數(shù)據(jù)庫。在特性方面，不僅緊跟sql標準的步伐，還有自身特有的功能，用的時候簡直爽到飛起來。 程序的業(yè)務邏輯， 基本上能在數(shù)據(jù)庫實現(xiàn)的就絕不會寫到代碼里面，久而久之，程序代碼基本上已經(jīng)沒什么東西了，就用來作為界面和數(shù)據(jù)庫的中轉(zhuǎn)而已。而且，sql server強大之處在于，盡管邏輯全寫在數(shù)據(jù)庫中，但是只要不瞎胡鬧，性能方面基本沒什么問題出現(xiàn)，再加上以visual studio為基礎(chǔ)的 management studio，就覺得.net和c#根本沒什么卵用了，直接數(shù)據(jù)庫可以搞定一切。不光是我，似乎大多數(shù).net系開發(fā)者都是這么做的。

后來跳了槽，從.net系轉(zhuǎn)到了php、java系，用的是mysql數(shù)據(jù)庫，然后我把之前開發(fā)sql server應用程序的那套思路搬了過來開發(fā)mysql應用，結(jié)果被同事和上級各種吐槽各種阻攔，他們認為存儲過程、觸發(fā)器、視圖、復雜查詢之類的程序性能的毒藥，而且還影響代碼的可維護性，然而卻拿不出充分的理由，但是既然他們都堅持， 那我自己特立獨行也沒這個必要，畢竟他們?nèi)硕鄤荼?，我新來咋到也不能太張楊。另外，mysql沒有一個像樣的IDE，類似于navicat for mysql這種客戶端根本沒法和Microsoft SQL Server Management Studio相比，寫起sql代碼來要多不爽就有多不爽。久而久之，數(shù)據(jù)庫在我的眼里就只剩增刪查改功能可以用了。

所以 我覺得mysql對sql標準支持的不完善的原因在于，因為這些特性本來就不是必要的，完全可以用程序來實現(xiàn)，對于基于mysql程序的開發(fā)者說，完全是可有可無的，而且還有可能引起某些極端分子的不滿，既然如此，那mysql團隊自然不會有動力去開發(fā)這些功能， 因為開發(fā)者根本沒有強烈的需求需要這些功能，這可能就是所謂的mysql文化吧。另外，如果誰能開發(fā)出一套類似于sql server那樣的數(shù)據(jù)配套工具，那說不定能培養(yǎng)出一批像微軟技術(shù)棧那樣開發(fā)者， 把sql能發(fā)揮的威力全炸出來，到時候說不定mysql團隊對于sql標準支持的腳本也會漸漸跟上了。

延伸閱讀：

二、主要的單機存儲引擎

1、哈希存儲：hash的CRUD是非常快的。但缺點是不支持順序掃描。bitcask是一個基于hash表結(jié)構(gòu)的存儲系統(tǒng)。他將寫操作（包括刪除標識）追加到文件尾。并定期合并新老文件&記錄。

2、B樹：既支持隨機讀取又支持范圍查找的系統(tǒng)。查找時間復雜度為logd(n)（d為每個節(jié)點的出度）。Mysql的InnoDB的引擎和OS的文件系統(tǒng)使用的就是B+樹。（為什么選擇使用B樹的變種B+樹，讀者有興趣可以去探究下。提示：磁盤讀取）

3、LSM樹(Log Structured Merge Tree)：由B+數(shù)改進而來。其思想為：將增量寫操作保存在內(nèi)存中，超過閾值時刷入磁盤，從而減少隨機寫磁盤操作。讀操作則需要合并磁盤數(shù)據(jù)和內(nèi)存中的寫操作。通過Memtable/SSTable實現(xiàn)，實現(xiàn)細節(jié)在此不做深入探究。比較適合寫操作較多的業(yè)務場景。BigTable/HBase/Cassandra中的列簇的數(shù)據(jù)存儲方式采用的即是LSM樹。