Mysql5.6以后，说 innode 的 select 性能不输 myisam 了，为什么

InnoDB存储数据字典，这意味着MyISAM已经可以完全从MySQL数据库中剥离；

Invisible Index，Inside君对这个特性非常感兴趣。因为在生产环境中，可以通过sys库判断哪些索引是冗余的。但是要直接删除冗余索引又担心会存在一些风险。Invisible Index给了我们很好的选择；

角色表功能，官方MySQL终于提供了Role功能。InnoSQL傲娇的表示我们在5.5就实现了此功能，甚至比MariaDB还要早。要知道在游戏行业，定期密码修改总是一个令人头疼的问题，有Role就简单多了。当然，InnoSQL还可以对Role进行资源控制，不知道8.0实现的怎样；

Cost Model改进，优化器能够感知到页是否存在缓冲池中。5.7其实已经开放接口，但是不对内存中的页进行统计，返回都是1.0；

直方图支持，MySQL也支持直方图啦。应该会有更好的执行计划。海翔兄在IMG大会中说到过此特性，听说性能提升非常不错；

参数持久化，继续与Oracle数据库靠近，但本身这个特性就是硬需求。话说这些年有多少因为没有参数持久化导致的坑发生；

扫描性能的改进，InnoDB全表扫描或范围查询性能提升5%~20%。请问之前HT写的代码有这么烂？

重构BLOB的实现，从而提升JSON属性的更新。个人感觉这方面性能的提升可能会非常大。留个爪，后面进行测试；

持久化自增值，这些年淘宝、Percona都做过类似的改进。但是官方的修改就是优雅，自增写redo，一个历史遗留难题就这么简单而又优雅的解决了；

PS库添加索引，官方宣称添加了100多个索引。的确，Inside君遇到过很多时候PS库占用20G内存的场景，这时查询就会显得非常不高效。但是内存开销会不会进一步提升呢？让我们拭目以待吧；

MySQL in NodeJS 是否能够等待全部 query 回传结果才继续执行

mysql数据库中的3个权限表：user 、db、 host

权限表的存取过程是：

1)先从user表中的host、 user、 password这3个字段中判断连接的IP、用户名、密码是否存在表中，存在则通过身份验证；

2)通过权限验证，进行权限分配时，按照useràdbàtables_privàcolumns_priv的顺序进行分配。即先检查全局权限表user，如果user中对应的权限为Y，则此用户对所有数据库的权限都为Y，将不再检查db, tables_priv,columns_priv；如果为N，则到db表中检查此用户对应的具体数据库，并得到db中为Y的权限；如果db中为N，则检查tables_priv中此数据库对应的具体表，取得表中的权限Y，以此类推。

事实上，在MySQL数据库中，诸多存储引擎使用的是B+树，即便其名字看上去是BTREE。

4.1 innodb的索引机制

先以innodb存储引擎为例，说明innodb引擎是如何利用B+树建立索引的

首先创建一张表：zodiac，并插入一些数据

对于innodb来说，只有一个数据文件，这个数据文件本身就是用B+树形式组织，B+树每个节点的关键字就是表的主键，因此innode的数据文件本身就是主索引文件，如下图所示，主索引中的叶子页（leaf page）包含了数据记录，但非叶子节点只包含了主键，术语“聚簇”表示数据行和相邻的键值紧凑地存储在一起，因此这种索引被称为聚簇索引，或聚集索引。

这种索引方式，可以提高数据访问的速度，因为索引和数据是保存在同一棵B树之中，从聚簇索引中获取数据通常比在非聚簇索引中要来得快。

所以可以说，innodb的数据文件是依靠主键组织起来的，这也就是为什么innodb引擎下创建的表，必须指定主键的原因，如果没有显式指定主键，innodb引擎仍然会对该表隐式地定义一个主键作为聚簇索引。

同样innodb的辅助索引，如下图所示，假设这些字符是按照生肖的顺序排列的（其实我也不知道具体怎么实现，不要在意这些细节，就是举个例子），其叶子节点中也包含了记录的主键，因此innodb引擎在查询辅助索引的时候会查询两次，首先通过辅助索引得到主键值，然后再查询主索引，略微有点啰嗦

---