为什么MySQL对SQL标准中很多基本用法都不支持

因为当年，在微软.net技术栈下开发应用，用的就是sql server数据库。在特性方面，不仅紧跟sql标准的步伐，还有自身特有的功能，用的时候简直爽到飞起来。程序的业务逻辑，基本上能在数据库实现的就绝不会写到代码里面。

一、为什么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树。