mysql难在哪里_写一个数据库最难的地方在哪？最精华的地方在哪？分几步？

数据库可以简单的分为查询引擎和存储引擎。

查询引擎是暴露给用户的编程接口。对于关系式数据库就是SQL语句的解析、优化和执行。但需要注意的是SQL是具备定制复杂查询的能力的。而且因为关系代数的完备性，使得大部分情况下，用户只需要写SQL语句就能完成常见的数据库操作。需要用户编程实现更加复杂的操作并不多见。

而对于非关系式数据库则相反，数据库本身通常提供的接口基本不具备编程能力，或只有简单的数据结构支持。很多操作都需要用户自己靠编程来解决。比如一个常见的联表查询在SQL里是系统平常的，数据约束等也是如此。而对于非关系式数据库，这些只能靠用户自己大量的代码来实现。所以想尝试自己实现个数据库的，可以自己选择这个折衷，把对数据库的复杂操作是交给用户还是数据库的设计者。

查询优化是个大坑，坑之大不是三言两语能解释清楚的，甚至不是一两本书能解释的。我可以给出个postgresql里的例子，是6年前我优化过。第一句是优化前，第二句是优化后：

SELECT * FROM post WHERE NOW()-dt_create<86400;

SELECT * FROM post WHERE dt_create>1234567890;

这里的dt_create字段是带有索引的，但是在第一句的比较左侧因为与NOW()函数做了计算，所以就没法利用索引了，而且因为NOW()函数在每个记录上都要重新求值，所以这个语句的执行是很慢的。

优化过程就是第一把NOW()函数去掉，改为从外部传入的当前时间戳数字，并且在外部做好与86400的减法。这样dt_create成了不等式一侧的唯一字段，就能利用好索引了。这样个优化使得速度提高了近20倍，功能却没变。

存储引擎的玩法也有很多，一些重要功能就是要在存储引擎里实现的，包括数据恢复、并发控制、索引等。

数据恢复的两大方法是转储和redolog。转储是把某个时间点整个数据库镜像保存到硬盘，缺点是时间较长，所以该操作启动后到数据库故障停止的时间里数据完整性是没法确保的。redolog则是把对数据库的每个修改操作都记一条日志，记完了日志才去更新内存镜像，记录快恢复慢。现代数据库更常见的是结合两者，平时任何更新都记录redolog，每隔一段时间把之前的更新做一个转储。这样可以兼顾数据完整性和故障恢复速度。

并发控制则是为了防止并发冲突的，对不同级别数据库玩法也有很大区别。粗糙一些的，每次更新操作都把整个数据库给锁了，更新完成再释放。这也是常见开源数据库的实现。高级一点的玩法能实现表级或行级锁，对于更新没有影响到的表就不会被锁住。锁的粒度更细使得更新对数据库的影响更小，同时设计复杂度也会增加很多。

题主如果只是希望学习数据库，自己设计个数据库来练手，则尽量降低第一个例子的门槛更有意义。对此我的建议是，实现memcache协议，做key-value数据库，底层引擎用一个全局锁的数据文件。稍微有心一点的可以在存储引擎上深入一些，比如学习一下数据结构课程里内存动态分配的章节，来做动态存储管理。之后再加上redolog支持，来实现故障恢复。那么这样一个业余项目就变得有趣很多了。

补充一下三种常见数据库的通信协议文档：