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

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

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

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

延伸閱讀：

二、主要的單機存儲引擎

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

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

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