最近的一些读者提问和解答
问题1：mysql中的存储引擎怎么理解？
能把存储引擎理解成存放数据的一种手段吗？
MySQL存储引擎是MySQL服务的核心组件，它规定了数据存储时的存储结构。
可以举个生活的例子来说明，假设有一个两居室，客厅就是MySQL Server,主卧是InnoDB,次卧是MyISAM,对于一个房间来说，假设住户是数据，那么住户只会在卧室里面休息，即数据是在InnoDB中存储或是在MyISAM中存储，对于数据的存储方式不同，主要基于事务安全、存储限制、空间使用、内存使用、插入数据的速度和对外键的支持等一些维度，可以有如下的一些存储引擎。
当然存储引擎这么多，可以列举几个目前使用率比较高的，这些存储引擎的一些相关维度的特性如下：
从MySQL的近些年发展来看，官方对于InnoDB的支持力度是越来越大，已经成为了MySQL存储引擎界的杠把子了。
归根结底，存储引擎在MySQL里面是一个插件式存储引擎，它还有很多兄弟姐妹（MyISAM,Memory,CSV等），但是在开源红利下，最流行最经受考验的还是InnoDB.
补充，存储引擎这个概念在Oracle中是没有的，或者说Oracle中只有一种存储引擎，这是MySQL和其他数据库的一个很大的不同。
问题2: MGR启动时的参数问题
问题:
第一个初始化的节点dang了之后，再次重启还需要set boot strap group参数吗？还是不用设置直接start group replication。
答：:
单主模式不用
问:
如果三台机器可同时写呢？单主我知道，三台机器一主写，其他两天负责做备机读，不好意思，对这些参数理解不是很深刻，我看了官方文档，再细细体会一下
答:
多主模式的话，有个single_primary参数是false,至于boot_strap这个是没有关联的了。因为故障后主库已经切换了。
问:
我可以这么理解吗？多主模式下，原来第一个set过bootstrap的节点dang了，只要把数据库启动，再start replication，它会自动加入，二三节点所在的组
答:
理论是可行的。
问题3: 新书的问题反馈
您好，杨老师。我正在阅读您的 MySQL dba工作笔记。受益匪浅。读到四分之一了。但是书中有一些印刷或者书写错误的地方。我正在一边读一遍整理。这个可以在哪里反馈？
答：最近写了一篇，可以在这篇文章下面留言。
注：
我对此可以保证的是，对于反馈问题最多的读者，可以提供如下几种好处和福利：
1）新书再次印刷前，我会和你确认，把你加入到本书的感谢列表中
2）新书再次印刷后，我会把最新的样书邮寄给你
当然技术交流不属于利益范围，没法用一些物质方式来量化，也不能够，希望我们能够成为朋友。
问题4：slave_master_info和slave_relay_log_info中的Master_log_pos不一致
问题的背景是一位读者发现在主库做任何修改时，在从库中只有slave_relay_log_info中的Master_log_pos在变化，而slave_master_info中的Master_log_pos竟然不发生变化。
读者解答：很高兴看到这位读者通过自己的方式解决了这个问题，是由于
sync_master_info导致，这个参数控制从库多久更新一次slave_master_info，默认是10000，即每10000个events更新一次。
读者参考链接：https://www.cnblogs.com/ddzj01/p/11505968.html
问题5：学习数据库的迷茫
问：杨老师，我想请教一下您，我这几天有点迷茫。
当前人家都在去O，而我却在学习O，是不是跟不上时代的潮流？
答：
O已经过了成熟期的发展 现有份额还是比较大 尤其在传统行业 后期增长的空间和开源方向比要小很多
问：那我该如何是好？O 还没学精通，再去干别的是不是有点得不偿失
答:
你的工作中会用到 那就把它学好 不用太内核那种学习 同时学习其他数据库扩展
问题：关于LRU的一些疑问
问：杨老师，刚开始看您的《mysql dba工作笔记》一书，在第2章 体系结构，LRU一节中，提到了全表扫描的表如果进入sublist of new bloc区域，会导致整个lru是性能瓶颈，而且mid的位置的也不是永久的，这种情况也叫缓存污染。这块内容没有读懂，请问老师，1，怎么理解 “mid的位置也不是永久的”这句话？2，全表扫描的表，在innodb中是怎么使用缓存的？3，innodb_old_blocks_time为何能防止缓存污染。
答：第1个问题，mid是计算出来的一个值，它对应的是相关的一些页所在的位置，页大小是固定的，如果全表扫描就会大量锁定某一些页，导致其他的页被刷掉，反复加载
为了解决这个问题，InnoDB存储引擎引入了innodb_old_blocks_time来表示页读取到mid位置之后需要等待多久才会被加入到LRU列表的热端。可以通过设置该参数来保证热点数据不轻易被刷出，这个参数值默认为1000（毫秒）。
第2个问题，可以参考我书里面的第2章第56页内容。
其中page cache是文件系统层面的缓存，数据库层面最直观的表现就是首次查询数据的时候会慢一些，之后就会快得多，整个过程是把磁盘里的数据加载到这个缓存里面。
另外一部分是buffer cache，其实指的是磁盘等块设备的缓冲，比如内存里的数据要写入磁盘文件，是一个异步的过程，而且为了防止断电丢失数据库，会按照一定的策略把数据刷新落盘。如果结合最开始的InnoDB体系结构图，其实整体要表达的含义是类似的。
问题3：InnoDB在LRU列表中加入了参考点，也叫midpoint。传统的LRU算法中，当访问到的页不在缓冲区会直接将磁盘页数据调到缓冲区队列；而InnoDB并不是直接插入到缓冲区队列的队头，而是插入LRU列表的midpoint位置。这个算法称之为midpoint insertion stategy。默认配置插入到列表长度的5/8处，和数学中的黄金分割（0.618）很接近，midpoint由参数innodb_old_blocks_pct控制，因为插入的位置不是从头部插入，所以全表始终是在刷新后半部分的页，而且可以通过超时设置置换出去。
问题:
问：经常看你的公众号，学习了不少mysql这块的东西，最近接了一个需求，老大要求要对schema变更进行管理，折腾了几天，没有一个有效的思路，想咨询下杨哥有啥建议么
答：这块本质上是在做数据生命周期管理， 这块的工作看起来很简单，但是要把流程打通，保证流程稳定可用还是需要下一些功夫的，