这是我参与11月更文挑战的第27天，活动详情查看：2021最后一次更文挑战
MYSQL
2.1 存储结构
-
事务：
- InnoDB支持事务
- MyISAM不支持事务，这也是Mysql将默认引擎切换的主要原因之一
-
外键
- InnoDB支持事务
- MyISAM不支持事务，如果将包含外键的InnoDB转换为MyISAM会失败
-
索引
-
InnoDB是聚簇索引：
- 文件存放在主键索引的叶子结点，因此必须有主键，通过主键索引会很快
- 辅助索引需要两次查询，因为辅助索引存储的是主键Id，再通过主键索引去查询
- 因此主键不应该设置太大，不然其他索引也会很大
-
MyISAM是非聚簇索引
- 数据文件是分离的
- 索引保存的是数据文件的指针
- 主键索引和辅助索引是分离的
-
-
行表锁
- MyISAM是表锁，操作一条数据也会对整个表锁住；并发访问受限
- InnoDB是行锁，这也是Mysql转换默认存储引擎的重要原因之一
-
行数
-
InnoDB不存储表的行数，所以执行 select count( * ) 语句时，会全表扫描，最后返回总数量
-
MyISAM内部维护了计数器，并把表的总行数存储在磁盘内，需要的时候直接调用即可
-
总结：MyISAM比InnoDB快，为什么不像MyISAM一样，存储在磁盘？
-
InnoDB中，数据量越来越大的时候，因为是全表扫描，性能会很低下；
-
为什么不像MyISAM一样存储在磁盘呢，这根Mysql 的事务特性有关，由于多版本并发控制(MVCC)的原因，InnoDB应该返回多少行也不确定
-
MVCC：多版本并发控制，也就是确保事务在当前时间段内不会遭到改变，通过在数据库内隐藏字段实现，版本号
-
-
后续关于Mysql的索引会在下一篇详细介绍
彩蛋
策略模式
根据不同类型采取不同的解析方式
对if / else 和 switch / case 进行解耦
1.1为什么不用if /else 和 switch / case
-
如果日后分支变多，业务有改动，那这个判断的代码将会变得臃肿，难以维护，可读性差
-
如果需要接入新的业务，需要在原有的代码上继续叠加（屎山跳舞）
-
用专业的话就是违背了面向对象编程的开闭原则和单一原则
- 开闭：拓展开放，修改封闭
- 单一：修改业务逻辑需要在原有代码修改
1.2实战使用
业务上是与硬件传感器交接，抛开连接框架（emqx）与连接协议（mqtt）；还是Netty和808
当数据消息上发到服务端，都是要经过业务层去分发到不同的设备service，走不同的逻辑处理
-
利用接口或者抽象类，里面都是两个方法，
- 一个是用枚举类，存放不同的业务（判断走向）
- 一个是实现方法，业务逻辑
-
实现ApplicationContextAware 接口（通过上下文环境对象获得spring容器内的bean），用一个HashMap存放相应的判断条件和业务逻辑处理，通过不同的条件，调用map里面不同的value实现类
