本文目录一览：
自己建的数据库放在mysql8什么地方?
默认在安装目录的data文件下，数据库创建时会生成和数据库同名的文件夹，该文件下既是数据库文件。
mysql8好用吗？现在用的多吗？
mysql8 可以说是一个质的飞越。增加了很多新特性，以及提高了各方面的速度。增加了开窗函数
Ⅱ InnoDB增强
自增列方面
自增列方面。现在自增列计数器会在每次值修改时，将值写到REDO LOG中，并且在CHECKPOINT时写到存储引擎私有的系统表中。
这就消除了以往重启实例自增列不连续的问题（这也可能形成了一个新的竞争点（盖国强会上提问InnoDB开发者））。
Btree索引方面
Btree索引被损坏。InnoDB会向REDO LOG中写入一个损坏标志。同时也会CHECKPOINT时将内存中损坏页的数据记录到存储引擎私有的系统表中。
这也就促成了恢复时。两边一致的情形。索引不可用，并不会造成实例起不来。这很大程度上降低了之前使用innodb_force_recovery和innodb_fast_shutdown的必要。
提升了一致性。（对于一般DBA来说透明，知道有这么回事就好）
NoSQl操作
InnoDB memcached插件支持多个get操作（在单个memcached查询中获取多个键/值对）
和范围查询。（个人认为这个挺牛逼，有点像NoSQL，不仅仅是NoSQL）。
需要安装daemon_memcached插件，其中多了一个innodb_memcache schema,这个schema中有几张表,其中一张containers用来与InnoDB表之间做映射,，
然后通过接口访问Innodb表。然后会有一个11211的端口打开，用于建立连接。
好处是通过减少客户端和服务器之间的通信流量，在单个memcached查询中获取多个键/值对的功能可以提高读取性能。
对于InnoDB来说，也意味着更少的事务和开放式表操作。
死锁检测
新的动态配置选项innodb_deadlock_detect可用于禁用死锁检测，默认打开。 在高并发系统上，当大量线程等待相同的锁时，死锁检测会导致速度下降。 有时，在死锁发生时，
禁用死锁检测并依赖innodb_lock_wait_timeout设置进行事务回滚可能更有效。记得之前版本遇到死锁会自动回滚。以下截图来自MySQL5.7，与8.0默认相同。
（也就是说即便MySQL5.7也是有死锁检测的，并且自动回滚权重较小的事务（套死除外））。
尝试更改innodb_deadlock_detect参数为OFF。则遇到死锁时两个工作线程都会被堵塞。直到innodb_lock_wait_timeout设定的锁超时。
新的INFORMATION_SCHEMA.INNODB_CACHED_INDEXES表保存了Innodb索引缓存在Innodb buffer pool中的页数。
现在，所有InnoDB临时表都将在共享临时表空间ibtmp1中创建。
加密特性
支持REDO和UNDO表空间加密。
共享锁方面
InnoDB在 SELECT ... FOR SHARE 和 SELECT ... FOR UPDATE锁定读语句上 支持不等待（ NOWAIT）和跳过锁（SKIP LOCKED）的选项。也就是说以往加了共享锁之后必须手动释放。
这里如果没有锁就返回结果，如果有就报下面错误。
如果是用有锁就跳过，则无数据。
根据场景使用。反正都是秒回。降低了排查数据库超时的可能。
mysql8 ibdata文件丢失怎么恢复数据
因为磁盘空间不足，我的一个虚拟机服务器崩溃了。结果数据库服务器进程无法启动，数据也就无法导出。只能想办法从数据库原始文件 ibdata 和 frm 文件中恢复数据库。
因为没有经验，好不容易才找到了恢复方法。特此记录，以备后用。
磁盘空间不足之后，mysqld 进程无法启动，提示“Can't connect to local MySQL server through socket '/var/lib/mysql/mysql.sock' (2)”。这真是让人无比头大，数据库根本连接不上。
目录 Contents
1. 保存原始数据库文件
2. 恢复方法
3. 参考资料：
1. 保存原始数据库文件¶
好在数据库原始文件还在。在我的系统环境和配置情况下，这些文件位于 /var/lib/mysql/ 文件夹下面。假设数据库名是 test，则这些文件表现为：
--mysql
|--test
|--1.frm
|--2.frm
|...
|--mysql
|...
|--ib_logfile0
|--ib_logfile1
|--ibdata1
|...
这些就是原始数据库文件，可以用来恢复数据库。将这些文件额外保存一份，以防万一。
2. 恢复方法¶
我的原始虚拟机完全没有磁盘空间而无法启动数据库服务器进程。虽然试着删除一些不需要的文件，但是数据库却始终无法连接。于是我新建了一个几乎一样的虚拟机（当然磁盘加大了），试图将这些数据库文件导入并恢复数据库。
在经历了很多错误之后，终于找到了正确的方法：
安装完成新服务器之后，通过命令行新建了与原来一样的数据库：数据库名称、用户名、密码都一样。如果有多个数据库需要恢复，就都给建好。（跟配置新服务器一样，参见安装和配置 MYSQL 数据库服务器。）
停止 mysqld 进程
service mysqld stop
将备份的原始数据库文件中的所有 .frm 文件（保持原来的目录结构）和 ibdata1 文件复制到新服务器的数据库文件目录中（如果新服务器操作系统和配置环境一样，那么目录结构也一样），其它文件不要。
使用 -innodb_force_recovery=6参数启动数据库服务器进程，这里是
/etc/init.d/mysqld start -defaults-file=/etc/my.cnf -standalone -console -innodb_force_recovery=6
OK，数据库恢复完成。
