在代理模式（Proxy Pattern）中，一个类代表另一个类的功能。这种类型的设计模式属于结构型模式。
在代理模式中，我们创建具有现有对象的对象，以便向外界提供功能接口。
策略模式旨在不改变被代理对象的基础上进行方法增强。
当我们一个原有的类不能满足功能，又处于职责或其他原因不便修改的时候，我们可以使用代理模式。通过代理类去调用被代理类的方法，在原方法的基础上进行各种加强，又不会改变原代码。
spring 中的 AOP 就运用了代理模式。
为了简单的说明代理模式，我们举个例子：
首先有一个接口，叫做购房者，然后这个类地下有一个实现类，叫做小明:
1 | //购房者接口 |
买房子还要货比三家，小明没时间，于是就把买房子这件事情委托给中介
今天在舍友的安利下发现了一个新的宝藏，阿里的数据库内核日报，内容之全面让小白我瞠目结舌，简单的爬了一下 mysql 相关的文章。
完整版可以直接点击链接下载。以下只是 Mysql 内容的整合：
slowlog与CSV引擎 - 2019/07/08/今天在舍友的安利下发现了一个新的宝藏，阿里的数据库内核日报，内容之全面让小白我瞠目结舌，简单的爬了一下 mysql 相关的文章。
完整版可以直接点击链接下载。以下只是 Mysql 内容的整合：
slowlog与CSV引擎 - 2019/07/08/此文为极客时间：MySQL实战45讲的39节的学习笔记
我们前面提到过，自增主键的连续性使得表在空间上排列的更紧密，提高了空间利用率，避免了页分裂。实际上，自增主键大部分情况下可以保证连续性，但是也有例外的时候。
当我们创建表的时候，表结构会存储在 .frm 文件中，但是并不会一起保存自增值。MyISAM 引擎将自增值保存在数据文件，而 innodb 在 mysql8.0 之前只会将自增值保存在内存。
也就是说，对于 innodb 引擎来说，每次重启后，都需要寻找表中最大的自增值 X，将 X+1 作为新的自增值，如果当前最大值为 10，自增值就会是11，如果删除了自增值为 10 的行，那么此时重启数据库，新插入的行自增值就会变成11，当自增值是主键的时候，相当于从新增变成了更新。
而 8.0 以后，innodb 会将自增值的变更记录到 redo log，重启以后依靠日志重做。
在 mysql 中，如果字段 id 被定义为 AUTO_INCREMENT，那么插入时：
根据要插入的值和当前自增值的大小关系，自增值的变更结果也会有所不同。假设，某次要插入的值是 X，当前的自增值是 Y。
此文为极客时间：MySQL实战45讲的16节order by相关内容的笔记
假如此时有这么一张表：
1 | CREATE TABLE `t` ( |
现在要按姓名排序查询杭州1000个人的信息
1 | select city,name,age from t where city='杭州' order by name limit 1000; |
这条 sql 的执行流程如下：
因为先查了全部需要字段才排序，我们把这个叫做全字段排序。
此文为极客时间：MySQL实战45讲的 34、35节join相关内容的笔记
假设我们有表 t1 和表 t2，他们都有字段 a，b，其中 t1 有 100条数据，而 t2 有1000条数据。
我们要执行这么一条sql：
1 | select * from t1 join t2 on t2.a = t1.a |
执行流程就是会这样的：
其中，被驱动表的关联条件是否有索引对性能有着很大的影响。
此文为极客时间：MySQL实战45讲的14节count相关内容的笔记
count() 函数用于查询数据的数量，不同的引擎有不同的实现。
在 MySAM 引擎会专门记录表的总数；而在 innodb 中，由于 MVCC 的原因，在统计数量的时候需要一行一行的判断当前数据是否对查询的事务的可见的。此外，show table status的 Rows 字段也能获取表的总条数，但是这只是预估值，实际上并不准确。
因此，表的遍历是无法避免的，但是 innodb 也有针对此做出优化：
主键索引树的叶子节点是数据行，而普通索引树的叶子节点是主键，针对 count 操作遍历那颗树都是一样的，因此查询的时候回找到最小的那颗索引树进行遍历。
计数这个功能通过 redis 也可以实现，即在 redis 中设定一个值用于计数，但是在遇到异常停止服务后不免会遇到数据丢失的问题。
如果结合 mysql 来做，即 redis 更新数据后再变更数据库里的数据，读取的时候直接从 redis 读，这样虽然一定程度避免了数据丢失的问题，但是却有可能导致数据不一致。举个例子：
现在计数是5，我们要为计数+1
此文为极客时间：MySQL实战45讲的元数据锁相关部分问题的思考总结
前面在锁这块介绍了元数据锁（MDL 锁）。元数据锁是一种读写锁，他的读读不互斥，读写和写写是互斥的。因此我们参考下面的时序图：
现在等待队列中有四个 session 要获取锁：
上面是一个很典型的读写锁堵塞的场景。但是实际测试的时候，会出现 sessionC 和 sessionD 都堵塞了，但是将 sessionA 和 sessionB 提交以后，sessionC 仍然保持堵塞状态，必须等 sessionD 也提交以后，才会继续执行。也就说，sessionD 好像发生了一个插队的现象。
我们知道 mysql 有一个 online ddl，即 执行 ddl 的时候不会直接锁表导致无法执行其他查询的操作。其实这涉及到一个锁降级的概念。即原本流程是：
此文为极客时间：MySQL实战45讲的 21、30、40节锁相关部分的总结
间隙锁加锁的情况，包含了两个“原则”、两个“优化”和一个“bug”。
以下面的表为例：
1 | CREATE TABLE `t` ( |
我们需要注意一下，c 是加了索引的，而 d 没有。直观点就是下图：
针对我们熟悉又深恶痛绝的空指针异常 NullPointException，JDK8 新增了一个用于处理可能出现的空对象的类 Optionalt ，也就意味着。他可以理解为对对象的包装类，对原本的类进行了增强，结合 Lambda 表达式和函数式接口，我们可以安心的操作一些可能是 null 的对象，避免繁琐的空值检验。
举个例子：
我们常见过一些处理对象的方法，有些时候经常能见到这样的写法：
1 | public static Optional<TestBean> getBean() { |
有些时候可能是try-catch块的限制，或者一些其他什么原因，我们的方法可能会返回一个 null，这样对于调用方来说，如果没有做空值检验就很有可能报 NPE，使用 Optional，我们可以显示的声明返回值可能是 null，并且返回一个 Option 类，调用方可以直接使用内置的方法进行处理。
1 | public Optional<TestBean> getStr() { |
在开始了解如何创建 Optional 对象之前，我们要明确，和 Integer 一样，Option 分为类本身与成员变量 value，其中 value 是可能为 null。
创建 Optional 对象有三种方法：