与RDB持久化方式不同的是，AOF持久化是通过保存Redis服务器的写和选择db的命令实现。AOF持久化的方式，很容易让aof文件变得很大，同一个key，比如来来回回被设置删除，更改内容，因此需要对AOF重写，来压缩文件大小。

有两个命令可以执行RDB文件持久化，分别为save和bgsave，其中save会阻塞主进程进行持久化，这时候Redis服务器是不能接收和处理客户端发来的指令的，而bgsave则是派生一个子进程，进行同步，该命令不会阻塞主进程继续执行客户端传过来的指令，此时的不阻塞主进程。

我们都知道Redis是基于c语言开发的，c语言没有垃圾回收机制，所以Redis自己实现了一套垃圾回收机制，Redis的垃圾回收机制是通过计数来实现的。基本逻辑是：创建对象时计数被初始化后为1当对象被新的逻辑使用，其计数加1对象被逻辑用完，其计数减一当对象的计数为0时，对象的内存被释放

最近这两天几乎被某多多的员工猝死事件刷了屏，各种感慨和惋惜，正是美好年华，未来有着无限的可能，然而却止住了前进的脚步，静静的去了别的世界。这值得我们思考，最近几年类似的事情层出不断，为什么一直会有？我们到底该怎么选择？

索引列不能是表达式,提高索引的选择性,理解聚簇索引和非聚簇索引,使用explain验证我们书写的sql语句是否可以合理的利用索引，是否能提升查询效率，合理安排查询语句列顺序，避免使用多个范围条件。

首先明确的一点是MySQL的索引是在存储引擎层实现的没有特殊说明，谈论索引，多半说的是B-Tree，对于InnoDB来说每个叶子节点的逻辑页大小为16K。另外B-Tree对索引列是顺序组织存储，非常适合做范围查找。

本文记录了整数类型、实数类型、varchar、char、BLOB、TEXT、枚举类型、DATETIME、TIMESTAMP等，并记录了一些包括存储效率、查询效率、使用注意事项等等一些问题和实例

本文记录了MySQL在并发控制和事务方面的知识点，在实际应用中很有帮助，无论什么时候，只要有多个线程(或进程)同一数据修改数据，就会产生并发控制问题，看mysql如何巧妙的解决。

GIL全称Global Interpreter Lock。注意这里有个Interpreter(Cython、Jython)，这把锁只允许一个Python线程获得解释器控制权，简单说就是某一时刻只能有一个线程运行(单线程)。Python为什么还有GIL？

ID在实际生产中起着非常重要的作用，任务追踪，任务查询等等等，尤其是在数据库层面，如果有一个id(非主键)能做唯一索引那查询速度将变得快(常数级)的惊人，但是这种唯一索引最好使用数字，而且是增加的，分享一下分布式ID生成算法snowflake的部署和使用方式