场景1：为什么我的微信号就是绑定不了，而且也不能实现自动登录！
alter table user_info convert to character set utf8mb4 collate utf8mb4_general_ci;
执行上面那句SQL就可以了，将表改成支持emoji表情就行了，因为微信昵称是支持emoji表情的，所以有些人昵称中有相关表情，结果造成微信接口返回的数据无法落库，最后造成不能自动登录等等相关操作。
alter table temp_record change orignal_type original_type varchar(10);-- 修改表字段名称 alter table xxl_job_user rename to family_user;-- 改表名称 alter table product_info add max_amount varchar(100) COMMENT '最高额度(单位：万元)';-- 新增字段 alter table smart_product add INDEX `result_id`(`result_id`) USING BTREE;-- 新增索引
问题1：MySQL有哪几种索引类型？
NORMAL：普通索引，最为常见用的最多。
UNIQUE：唯一索引，对标数据库表中具有唯一业务的字段（建表所用字段，修饰关键字也是UNIQUE），例子：如果表中有身份证ID字段，天然就是一个不重复的。
FULLTEXT：全文索引，用于字段数据量较大的建索引，提高查询效率，但是数据量太大一般都用ElasticSearch中间件做一个倒排索引，这样能更好地提高检索效率，且不容易失效。
SPATIAL：空间索引，（见识少点，也没用过）
问题2：MySQL有哪几种索引方法？
BETREE：B+树，每层容纳节点数量大，且数据从左向右，从小到大排列，很好支持范围查找。
HASH：Hash表，单个数据查询时间复杂度O(1)，一次操作就行；但是不支持范围查找，因为Hash表的结构就是数据散列的。
问题3：EXPLAIN执行计划
1、Id列：id数值大的先执行，数值相等，位于上面的先执行，id为空，表示一个结果集，不需要使用它查询，常出现在包含union等查询语句中(下面有例子)。
2、select_type列：DERIVED from关键字后面的子查询，会产生衍生表；PRIMARY 最外层主查询；SIMPLE简单查询(不包含子查询的)； SUBQUERY from关键字之前的子查询；UNIOn 连接2个及2个以上的select查询(联合查询)。
3、table列：查询的表名称
4、type列：null>system>const>eq_ref>ref>range>index>all(性能由高到低排列)
null：聚合函数查询，直接索引树上拿数据；system：很少见，和一条记录进行比较；const：使用主键索引或唯一索引和常量进行比较；eq_ref：多表连接查询，使用主键进行比较；ref：查询条件是普通的索引列；range：主键索引做范围查找；index：查询没有进行条件判断，所有数据可以从索引树上拿；all：全表扫描。
5、possible_keys列：可能用到的索引
6、key列：实际用到的索引，与possible_keys一起看，改SQL有无走索引
如果possible_keys有索引，而实际是没有走索引，且type是all，说明MySQL内部优化器进行判断，走索引还不如全表扫描来得快些；一般的，普通索引的叶子节点存放主键值，查询到数据后再根据主键值，走主键索引查到数据，需要扫描2棵索引树，还不如一次性扫描表中全部的数据。
7、key_len：索引字符的长度，主要看你使用的索引字段，设计数据类型与长度，一般的，字符串：char(n)，varchar(n)，3n+2；数值类型：tinyint 1个字节，smallint 2个字节，int 4个字节，bigint 8个字节；时间类型：date 3个字节，timestamp 4个字节，datetime 8个字节。
8、rows列：该次查询可能查询的条数
9、Extra列：额外的信息，有
using index：覆盖索引;
using where：使用索引列进行范围查找;
using index condition：普通索引查询，需要查的列并没有完全被索引覆盖;
using temporary：会创建临时表来执行，比如在没有索引的列上进行去重操作，就需要临时表来实现;
using filesort：使用了文件排序，会使用磁盘+内存的方式进行文件排序。
问题4：InnoDB与MyISAM的区别是？InnoDB是怎样支持事务的？
InnoDB支持事务，MyISAM 不支持事务；
InnoDB会根据Redo Log进行事务提交后的持久化；根据Undo Log进行事务失败后的回滚操作；
以一个updatue语句为例：
1、InnoDB在收到一个update语句之后，会根据条件找到数据所在的页，并将该页缓存在buffer pool 中；
2、执行update语句，修改buffer pool中的数据，也就是加载到内存中的数据；
3、针对update语句生成一个RedoLog对象，并存入到LogBuffer中；
4、针对update语句生成一个Undo Log日志，用于事务回滚；
5、如果事务提交，那么则把RedoLog对象进行持久化，后续还有机制将buffer pool中所修改的数据页持久化到磁盘中
6、如果事务回滚，则利用Undo Log日志进行回滚。
问题5：事务的传播特性
一共有5个，一般用的比较多的是REQUIRED(默认的)和SUPPORTS；都是放在@Transactional注解里面的
1、方法A调方法B，注解都是放在方法B上的；
2、REQUIRED：如果方法A当前有事务，那么方法B的事务就加入进去，AB里面的SQL要么全部成功，要么全部回滚；如果方法A不存在事务，那么方法B就新建一个事务，自己执行，成功就提交，失败就回滚；
3、SUPPORTS：如果方法A存在事务就加入进去一起变成一个事务，如果不存在事务，方法B就以非事务方式运行。
以上就是我最近温故而知新的初见，欢迎大家品评、探讨；如果今后发现查漏补缺，会再修正！
