浅谈数据库框架,见笑,请多指正

浏览数：21 / 时间：2015年06月12日

浅谈数据库框架,见笑,请多指正

http://weibo.com/p/1001603724746155003486

一友说"插件式存储又割裂了SQL引擎的完整逻辑...总体而言在现有框架下MySQL的优化器没有多大改进的价值".

我们且做个技术分析:

1 插件式框架,可以静态/动态加载组件,方便在同类不同属家的模块间切换,这种设计是良好的. 很多软件的设计都采用了"微内核+插件"这样的方式构筑了强大的应用.如Ecplise生态圈.

2 数据库范围内, MySQL的属于插件式, 还有无其他数据库也有插件式的设计呢? 答案是:PostgreSQL的存储层也是插件式. 这点可以从f_smgr结构体可以看出(分析smgr层, 可以参看 @那海蓝蓝的博客:http://blog.163.com/li_hx/blog/static/183991413201172483824324/ 之 http://blog.163.com/li_hx/blog/static/18399141320117266474331/ 和 http://blog.163.com/li_hx/blog/static/18399141320117258368583/ ),只是PG这些年的发展,一直没有生长出独立且有影响的存储层,所以这一点鲜为人知. 也许这给大家造成了MySQL独家使用插件式设计的印象(此一句是妄测的,见笑).

3 "插件式存储"一说如果改为"插件式事务与存储引擎"更为妥当, MySQL的server层只定义了事务的接口,具体实现ACID特性的,还是server层下如InnoDB一类的插件实现了事务与存储功能. 强调这个,其实是在强调数据库系统的本质--事务, 如果只理解InnoDB为存储引擎则可能谬以千里了. 这也是越来越多的人舍MyISAM等而选InnoDB的内在原因,选的是事务保障而非简单的存储.

4 一旦模块被加载,在运行态,他们就是一体的,效率高低不取决于是否是插件式(插件式的设计在运行态下,只是函数指针技术的应用,没有效率损失). 而插件式设计的优劣在于接口层是否考虑妥当.

对于插件式设计而言,如果接口层把需要执行的任务/需要传递的信息规定清楚,则运行态下和是否是插件式根本无关（动态加载的插件，只首次使用时加载耗费一点代价；InnoDB在启动时即加载所以连这一点儿影响也不存在）. 插件式设计只是设计层面的问题而非运行态的问题,所以"插件式存储又割裂..."不妥；如果硬要说割裂,那么其实可以认为是"接口层"定义的尚不清晰而不是“插件式”的过错。所以，“总体而言在现有框架下MySQL的优化器没有多大改进的价值"这句结论自然就不成立了。

5 额外谈谈MySQL优化器的未来。

这个是个特大话题，非三言五语能说透彻。更何况短短微博能轻易穷尽。

简单说：

1）MySQL优化器一直在进步，业内有识之士从5.6和5.7的源码中已经发现这一明证。大规模持续投入使的MySQL比历史上任何阶段都进步的快速。

2）任何数据库的优化器都在进步着，这是社会需求推动的。

3）MySQL的优化器在需求推动下如何进步？可以从技术和历史发展机遇（发展机遇暂且不讨论）2个方面来讨论。技术方面，MySQL优化器没有所谓的插件式框架限制其发展的伪命题存在，而MySQL内部不断的对优化器进行迭代式重构（这是架构的改进），不断地采用各种技术提高优化器的性能（这是功能的改进）。

4）更多技术细节：《数据库查询优化器的艺术》一书在第四篇第17章/第18章/第19章深入到细节，讨论了PostgreSQL和MySQL的优化器的异同和优劣，供参考。

6 框架

有关框架的更多讨论，欢迎更多的有实据的讨论和指正。

这是我的说法感觉插件式缺点确实不少, 比如InnoDB需要维护自己的一套数据字典, 每次向Server输出一条记录导致HASH JOIN实现困难等。MySQL的执行计划也很粗糙，作为执行器和优化器的接口，应该更明确、精细。