目的

　　想把项目里面的api工程发布到本地仓库，做了一个关于dubbo的demo，想测试下。

方案

　　在你要打包的工程的pom文件中，添加

<distributionManagement>
    <repository>
        <id>localRepository</id>
        <url>file:I:\repertory</url>
    </repository>
</distributionManagement>

　　然后右键项目，点击run as / maven build,在goals里面输入 deploy -e即可将你想打包的工程发布到你的本地仓库里面。

　　如果你要上传到远程私服。那么pom文件添加：

<distributionManagement>
    <repository>
        <id>nexus-releases</id>
         <name>NexusReleases</name>
        <url>http://192.168.14.217:9091/nexus/content/repositories/releases/</url>
    </repository>
    <snapshotRepository>
        <id>nexus-snapshots</id>
        <name>NexusSnapshots</name>
        <url>http://192.168.14.217:9091/nexus/content/repositories/snapshots</url>
    </snapshotRepository>
</distributionManagement>

　　然后在你的maven的setting文件里面添加：

<server>
    <id>nexus-releases</id>
    <username>admin</username>
     <password>admin123</password>
</server>
<server>
    <id>nexus-snapshots</id>
    <username>admin</username>
     <password>admin123</password>
</server>

　　然后和上传本地的方法一样的操作步骤。
mvn install –settings c:\user\settings.xml

全字段排序

　　当我们要进行排序，mysql会为当前线程分配一个叫做sort_buffer的内存来进行排序。
　　mysql根据sql,依照索引，把要查出来的数据从数据中一行行取出满足条件的数据全部放进sort_buffer，也就是说所有要查出来的字段全部加到sort_buffer里面。从而进行排序。
　　其排序方式可能就在内部完成，也可能因为内存不够数据量那么大，就要使用磁盘临时文件排序。存在sort_buffer不大，同时数据量很大的情况下，选出的数据会存为多个文件，那么很显然，我们使用归并排序的思想，对每个文件先排序，排好序后，然后用一个堆（大顶树或者小顶树）作为内存中暂存，然后一个一个元素丢到排好序的文件里面。

rowid 排序

　　当我们要排序的单行数据很多的时候，那么在内存的总行数就会不多，因此我们可以通过设置一个参数

SET max_length_for_sort_data = 16;

　　来使用另外一种算法来提高效率，这个参数就是单行数据字符数不超过１６才使用全字段排序算法。和前面的全字段排序不一样的是只把id+要排序的字段加到sort_buffer里面，其余的不加进去。这样sort_buffer里面放的行数就多了很多。然后排完序后，然后更急id从主键索引里面取出所有数据。

思索

　　这种排序体现了mysql的一种思想：如果内存够，就要多利用内存，尽量减少磁盘访问。第二个会回表，因此，默认和优先全字段排序，但是无论怎么说，mysql排序很消耗性能。
　　有个办法可以不用临时表，那就是联合索引把要排序的字段加到索引里面，那就默认有序了，我们查到一个就直接返回，直到遇到不满足条件的，或者limit到极限的。
　　或者更加优化，使用覆盖索引。

临时表

　　前面说了，对于innodb来说最好使用全字段排序，因为没有最后的回表操作，减少了磁盘io，但是对于存在于内存的临时表来说，回表操作不是磁盘io，那么肯定是优先使用rowid排序。

mysql> select word from words order by rand() limit 3;

　　比如上面的语句就创建了临时表，使用的是memory引擎，且这个表是没有索引的。对于上面的语句来说，表有2个字段，一个字段是rand()函数生成一个随机的小数，一个就是word类型的字段。然后从表中将数据全部取出来后放到这个临时表里面。然后对这个字段排序，排序规则就是根据我们生成的这个随机数，然后我们取出这个随机数，以及位置信息放到sort_buffer里面，对随机数进行排序，然后取出数据即可。
　　这里的位置信息相当于innodb里面的主键，因为在memory这个存储引擎里面是没有类似索引这种操作的，他是类似于数组。
　　再比如，innodb里面，你删除了主键，那么innodb就会生成一个长度为6字节的rowid作为隐藏的主键。

　　不是所有的临时表都是内存表。这个要依据tmp_table_size这个参数来确定，默认是16m,如果大于这个值，那么就用磁盘临时表（innodb），否则则是内存临时表（memory）。

新的算法

　　在mysql5.6之后引用了优先队列算法。比如上面的语句只要查出前面3个，如果使用归并排序，就是对所有数据进行排序，但是我们只要查出前面3个，那么我们就可以使用一个堆结构来存，从而迅速获取到前面3个值。但是如果limit过多，那么就不用这个算法，那就使用归并算法，因为这种情况下使用优先队列算法就划不来了。

排序很消耗性能，临时表更加消耗性能

　　我们要尽量减少创建临时表，和排序，若是没有办法，那只能如此了。

不同存储引擎

　　在Myisam这个里面，每个表的总数据数额外存了起来，每次读取，直接获取这个值，效率很高。但是在innodb里面，就需要一行行遍历，为什么呢，因为innodb采用mvcc多版本并发控制机制，不同事物下，读取的数目可能不一致。

解决方案

　　1.使用redis来缓存总量，在并发不是很高的情况下，没插入一条语句，redis就加一，删除一个数据，redis就减一。但是，插入数据和redis加一这操作不是原子操作，当要获取最新100条数据，和数据总量，如果有另外一个线程，在其中间执行，那么总量和最新数据无法保持一致。　　　
　　２．将其放在mysql的一个表里面。如此即可，按照和redis一样的策略。但是不存在上面说的问题，因为mysql的rr隔离性，只要开启一个事务，这2个操作就是原子的。

效率

count(字段)<count(主键 id)<count(1)~count(*)

表结构数据和表数据

　　mysql1.8之前，表结构数据和表数据分开放，表结构放在.frm文件里面。在1.8后就放到一起了。

innodb_file_per_table

　　这个参数off是表数据放在共享表空间里面。和数据字典放在一起，on则是表数据单独存为一个后缀为。ibd的文件，当你drop的时候，系统也会删除这个文件，mysql5.6之后系统是默认开启这个这个参数的，也就是说，一个表文件会放在一个文件里面。通常是默认开启的。开启利于管理维护，当我们进行drop时就会直接删除这个文件。从而释放空间，否则放在共享表空间里面，即使删除了，也不会释放空间。

问题来了

　　因此我们直接删除表的时候会直接删除这个文件，但是删除部分数据的时候，我们会发现表空间没有被回收。

innodb删除流程

　　我们知道mysql innodb存储引擎里面存数据的方式是基于b+树。当删除一个记录，找到这个数据的时候，我们是将其标记为删除状态，而不是真的删除。等到有相关数据的时候那就可以直接插入进去。但是删除了一个页，那就和数据不太一样了，数据的复用是有局限性的，但是整个页是没有问题的。换句话说，你删除了某个数据，你填充这个数据只能是相关的，比如，这个数据页里面是6,7,8，你删除了7，你可以插入6到8之间的数据.或者可以在这个数据页里面的，如果是数据页，那么哪里都可以。同时如果相邻2个数据页的数据利用率很低，那么就会触发合并操作。是的另外一个页数据可复用。当我们使用delete指令的时候，我们进行的是逻辑删除，具体的数据页没有被回收，只是将其置换为可用状态，同时插入也是同样的道理。当你插入的数据在一个已经满了的数据页中间的时候，就要进行分页操作，那样也会造成大量空间被置为可用状态，但是不回收。

重建表

　　使用了很长时间的表存在大量这样的数据空洞，因此我们可以重建表来获取更加紧凑的结构。使用alter table A engine=InnoDB来进行重建操作，在mysql 5.5之前，逻辑是这样的，先构建一个临时表，然后把数据复制进去，在交换表名，删除旧表。显然这样的逻辑是全表锁的。中间是不能插入删除更新数据的，但是在之后就可以了，就是在上面的操作的过程中，增加一个临时文件，用来存储在这中间的ddl操作，最后再将其同步过去。其过程是先加写锁，再加读锁。

简介

　　本文的目的是搭建一个具备elk日志监控的springmvc程序，代码里面将日志输出到redis里面，然后logstash配置input和output,将日志信息从redis里面取出来，然后放入Elasticsearch，然后启动kinaba，配置索引对应关系即可。最终可以通过kinaba可以实时看到日志，利于分析查询。

搭建一个springmvc的程序

　　这里我直接给出仓库地址：
点我一下就到了
　　这里要注意下。我们把日志输出到了对应的redis里面。

<appender name="LOGSTASH" class="com.cwbase.logback.RedisAppender">
    <source>SpringELK</source>
    <type>dev-type</type>
    <tags>dev</tags>
    <host>127.0.0.1</host>
    <port>6379</port>
    <key>logstash</key>
</appender>

软件下载

　　１，下载6.3.0版本的kinaba，Elasticsearch，logstash。
　　２，下载redis。

主要配置修改

　　１．Elasticsearch 在其配置文件Elasticsearch.yml

http.cors.enabled: true
http.cors.allow-origin: "*"

　　２．logstash 新建配置文件。

input {
    redis {
        data_type => "list"
        key => "logstash"
        host => "127.0.0.1"  #redis-server
        port => 6379
        batch_count => "1"
        threads => 5
    }
}

output {
  elasticsearch {
    hosts => ["http://localhost:9200"]
   index => "%{logstash}-%{+YYYY.MM.dd}"
    #user => "elastic"
    #password => "changeme"
  }
}

启动顺序

　　１．启动redis。
　　２．在tomcat里面启动spring mvc代码
　　３．启动Elasticsearch。浏览器进入 http://localhost:9200/
　　４．进入到logstash的bin 目录，输入logstash -f ..config/redis.conf来根据配置文件来启动logstash。浏览器进入http://localhost:9600/
　　５.直接启动kinaba 浏览器进入http://localhost:5601，然后配置es的索引，最终在discover里面成功看到了我们的日志。

表锁

　　这里表锁我只说MDl锁。也就是元数据锁，这个锁是表锁，其分为mdl读锁，mdl锁就是对一个表做增删改查的时候，加的就是mdl读锁，修改表结构的时候加的则是mdl写锁。
　　读锁－读锁互不影响。读锁－写锁互斥。写锁－写锁互斥。
　　当我们修改表结构的时候，对于大表，我们会仔细操作，因为这个操作会导致全表扫描。但是即使对小表修改表结构，也会造成严重影响。
　　举个例子：
　　查询，查询，改结构，查询。这４个，后面２个都会阻塞，因为读写互斥。如果后续请求很多，可能大量阻塞卡死。
　　那么如何安全的修改表结构呢？
　　查询当前长事务，看看你要变更的表是否在里面，如果在，等长事务结束，或者杀死这个长事务。

行锁

　　mysql的行锁是是存储引擎实现的。这边我专门说下innodb，因为myisam是不支持行锁的，因此对于高并发下，行数据是不安全的。在innodb里面，行锁是在你需要的时候加上去，比如修改某一行的值。修改完之后不是立刻释放，而是等事务结束后才释放锁。
　　在并发系统中不同线程出现循环资源依赖将会导致这几个线程进入无限等待的状态，称之为死锁。
　　下面情况出现死锁：
　　事务1 对表A的数据a修改
　　事务2 对表A的数据b修改
　　事务1 对表A的数据b修改
　　事务2 对表A的数据a修改
　　在出现死锁的情况有以下２种情况对其进行处理。
　　１．进入等待状态，直到超时。超时参数可以通过参数innodb_lock_wait_timeout来设置。默认是５０ｓ。一般不采用这个方式。
　　２．发起死锁检测，发现死锁后，主动回滚死锁链条的某一个事务，让其他事务得以执行。将参数innodb_deadlock_detect设置为０表示开启这个逻辑。我们一般采用这个方法。
　　但是这个是有代价的。该逻辑如下：每当一个事务被锁住的时候，就要看看它依赖的线程有没有被别人锁住，不断循环，最后判断是否出现循环等待，也就是死锁。
　　如果是所有事务都是更新同一行的操作，那么死锁检查操作就是每个新来的被堵住的线程都要判断是否是因为自己的到来而导致了死锁，如果是1000的并发，那么其操作则是100w量级的。这样会导致cpu 100%异常。
　　对于热点行数据更新问题。有以下方案：
　　１．确定不是死锁，把死锁检查关掉
　　２．做一个数据库中间件来判断来控制请求量
　　３．在代码层面吧热门行数据分割。

如何kill加锁的语句

　　我们使用show processlist可以查看当前所有的，但是大部分都是sleep的，因此不方便，但是我们可以使用 select blocking_pid from sys.schma_table_waits;查询出阻塞的线程id;
　　这个查询是查询表级锁的。

间隙锁

　　mysql为了解决可重复读的幻读问题，于是有了间隙锁，就是在加行锁的数据之间加一个新的锁，那就是间隙锁，依赖控制幻读问题产生。这个间隙锁，不仅仅只是在插入的时候有间隙锁的校验，还在你update的时候也有间隙锁的校验。间隙锁的冲突和行锁不一样，不是锁之间的冲突，间隙锁可以重复加，和间隙锁冲突的是往间隙锁里面添加内容。

加锁原则

　　１．加锁都是next-key锁，都是前开后闭原则。
　　２．只有访问到的对象才加锁。
　　３．给唯一索引加锁，next-key lock退化为行锁。
　　４．索引上的等值查询，向右遍历时且最后一个值不满足等值条件的时候，next-key lock 退化为间隙锁。
　　５．唯一索引的范围查询会访问到不满足条件的第一个值为止。
　　目前的mysql加锁都是基于上述规则。

二级索引与一级索引

　　在mysql里面，我们默认用主键作为一级索引，因此只有一个。主键索引对应叶子节点指向的是整行数据。而其他我们自己建立的索引则统统都是2级索引，二级索引的叶子节点指向的则是主键。因此我们根据二级索引查询数据的时候是先根据索引查询到主键值，在回表根据聚簇索引查询整行数据。

B+树

　　我们为什么用B+树，是因为其树高度不高。我们根据索引查询的时候，没读到一个数据都是对树高度的遍历。每一次读取都是一次磁盘io,磁盘io效率太低，因此我们大多使用相对更加矮小的b+树。

重建索引

　　有时候数据量大了，因为索引的分页操作，导致其占了很多空间，因此要重建索引，来释放空间。

覆盖索引

　　覆盖索引，指的是那些不需要回表的索引。也就是只用走一个ｂ+树。
因为我们要查询的内容已经在第一条二级索引里面获取到了。因此使用覆盖索引是个优化手段非常好的一个策略。

最左前缀原则

　　对于联合索引，（a,b,c），查询条件必须含有a才奏效，这就是最左匹配原则。还有字段模糊查询，必须是 “1%”之类的，前面的必须要有值。对于这种联合索引，a一样的，先按照b排序，再按照c排序。

mysql5.6之后的索引下推

　　在mysql 5.6之前，对于联合索引来说，在mysql5.6之前，mysql的联合索引中（a，b）,在查询里面where a=”” and b=””；这类的sql我们的索引只能用到a这个字段来过滤，b是用不到的。
　　在mysql5.6以及之后的mysql对其做了优化，不只是用到了a,还用到了b,这个就是索引下推，从而大量减少了回表操作。

索引不准

　　在mysql里面，优化器会对sql进行分析，判断来选择使用什么索引，当我们使用 show index 会发现index的基数不对，这个统计是粗糙的，是其随机选出n个数据页，统计其不同值，得到一个平均值，然后乘以页数，得到其值，同时，当数据量更新超过一定值的时候，会再次触发统计。这个基数是来判断同样的扫描行数下，谁的基数大，那么就用谁做索引。有时候优化器会使用性能不好的索引，我们必须手动指定，挥着删除该索引等。索引不准的原因可能是。开启了一个事务，。没有关闭，然后又新开一个事务，删除大量数据，由于undolog可能导致判断基数时失效。

前缀索引

　　对于字符串字段来说，我们可以给一些超长的字段加前缀索引，从而减少索引文件的大小，比如邮箱，我们只需要比对前面的。缺点是，无法使用覆盖索引，索引区分度下降，查询次数变多。ps(为什么区分度很重要，前面说过了，你用一个索引查询的时候，如果都是一样的，那么每次都要遍历索引，在遍历表，效率比全表扫描还低)。举个例子，对于身份证号，我们如何建立索引呢，如果直接建立索引，但是身份证号太长了，如果建立索引，索引文件会非常大的。采用方案如下，在新建一个字段，给这个字段加个索引，这个字段的值是根据crc32()计算出来的值，当我们根据身份证号查询的时候，2个条件都加一下，这样就可以，索引文件小了很多，同时索引区分度也很高。很赞。

索引遇坑事件

　　１．使用索引字段函数
　　当你查询的数据列使用了函数，那么即使这个字段加了索引，那么依旧不适用索引。索引字段不能用函数，但是索引字段参数是可以用函数的，因此不是加了函数就不用索引了。

　　２．隐式转换
　　比如你这个sql的这个字段varchar类型加了索引，但是explain一下后，发现没有使用索引，为何呢。
　　这是因为在mysql里面，字符串和数字比较，是字符串转为为数字，因此当你索引字段是varchar,参数是int的时候，mysql优化器会默认给你的索引字段加CAST(tradid AS signed int) 进行转换，当然若是索引字段是int，参数是字符串，那么就不会存在问题。因为是参数在转换。
　　
　　３．隐式字符转换
　　当２个表的字符集不同的时候，做表关联是用不上关联字段的索引的，很好理解，２个字符集不一样自然无法比较，那么就需要默认转换，这个转换和java的向上转型一样，都是向长度大的转型，因此有时候会对索引字段加函数操作，因此无法使用索引了。这个就要区分，谁被谁关联。我以前的文章说过，2个表2个字段都有索引，那么就是选择记录少的作为外表。记录多的走内表索引，因此，对于内表来说如果是被转换的，那么就无法走索引了，因为相当于对索引字段调用了函数。对此的优化方案，一。把字符类型修改。2数据量大，在参数那里就转换。
　　总结：索引字段不能使用函数，参数使用函数不影响sql.字符串转数字，utf8=utfmb4,

方法

　　１．我们使用Navicat来帮助。点击工具，在点击结构同步。出现一个界面。
　　２．点击对比，把要比较的２个库，一个源库，一个对比库填写进去，然后点击对比
　　３．点击查询修改，即可获得差异化信息。

原因

　　为了了解rpc的原理，以及为何使用netty做为通信框架。

简介

　　生产者：写好对外api接口以及实现类，然后在启动一个netty对外服务。
　　消费者：根据发过来的api接口，创建一个代理类，在代理类里面启动一个netty客户端，远程访问其服务，得到结果再返回。

项目地址

　　我也简单实现了一个仿写的rpc,demo如下：
　　点我一下就到了
　　极其粗糙的实现了一次，如有时间，继续优化。

redolog

　　MySQL 里经常说到的 WAL 技术，意思就是数据先写日志，再写磁盘。这里面的日志就是innodb里面的redolog.当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写redo log里面，并更新内存，这个时候更新就算完了，然后innodb引擎会在适当的时候将数据跟新到磁盘里面，这个跟新会在系统空闲的时候进行。
　　这个可以加速的原因是不用去索引磁盘里面的数据，直接添加到日志里面，等到最后清算，如此可以有效提高效率。
　　redolog是个循环日志，其大小固定为4g，存在2个指针来定位其是否已经满了。一个指针是当前写，一个指针是当前checkpoint,其2个指针的顺时针空间就是可写的空间。很类似java里面的bytebuffer。redolog本质上就是为了崩溃恢复用的。当内存的数据页要持久化到磁盘，这个脏页的操作和redolog无关。只有当崩溃恢复的时候才用，把数据修复为脏页数据。因为redolog记录的是数据页的变换信息。 redolog只是个保险。数据页只存在2个情况。内存中，那就一定是正确的结果，直接返回，另一种是数据文件上的，那就一定正确，读入内存后返回。

binlog

　　这个是mysql自身的日志，叫做归档日志。和redolog大致3个不同点。
　　１．其为mysql自带的，redolog是innodb里面的。
　　２．redolog是物理日志，binlog是逻辑日志。
　　３．redolog是循环日志，binlog是增量日志。
　　对于我们来说，redolog主要针对系统崩溃，而binlog主要是针对系统恢复归档，因为redolog是循环的，无法持久太多。

　　我们如何将数据库恢复到一周内的任意状态？

　　我们这么做的，首先你的binlog保存了最近一周的binlog,然后你先将库恢复到一周前的全量备份里面去，然后再从binlog里面取出数据，重放到你想放的那个时刻。

undolog

　　这个日志主要用来处理事务的隔离级别的
　　详细信息请看我的另一篇文章，关于mysql innodb的隔离级别的实现。因此我在这里说下长事务对其的影响，我们知道我那篇文章说了，innodb是基于mvcc的控制，undolog将会非常的大，因为这个日志的大小和最早事务相关，因此长事务会使其的undolog非常大。
　　大家也不想使用长事务，但是以下情况可能出现长事务。就是你
　　set autocommit=0那就是不自动提交，即使是一个select语句那也不会提交，因此我们要注意。
　　我们用这条语句来判断事务是否为长事务。
　　select * from information_schema.innodb_trx where TIME_TO_SEC(timediff(now(),trx_started))>60

change buffer

　　这个东西主要是更新插入数据时用的哈，首先判断要更新的数据是否在内存，若在，直接更新内存，如不在，则是将其修改加入到change buffer里面，等到要查询这个数据的时候，再将其同步过去。或者等到一定时间通过定时器刷新过去。但是要用到这个东西不能加唯一索引，因为你加了唯一索引，那么就必须从磁盘读取到这个数据页来进行判断这个数据是否满足规范，因此要想用到这个change buffer就不能用唯一索引，只能用普通索引。那么这个change buffer和redo log的区别呢？在数据库的操作流程是这样的。假设这个数据不在内存里面，我们的操作流程是先写到change buffer里面，在写到redolog里面，当我们要读取这个数据的时候，我们从数据库里面读取到这个数据页，然后取出对应数据加上change buffer的东西。

　　因此相对于redolog,change buffer主要是减少了随机读取的性能消耗，因为我们不用读取这个数据页，插入更新的时候，只有当我们真正需要读取数据的时候才进行读取数据。而redolog则是有效减少了随机写磁盘的消耗，我们只用顺序写到redolog里面，当到一定时间后则刷新到数据库磁盘里面。完美。ps:这都是针对2级索引，而主键索引是判断数据所在数据页的在哪的，因此考虑了其唯一性。，其实２者没必要比较，是不一样的概念。

​ redolog只是灾难备份用的。正常的数据页持久化磁盘，是内存里面的数据页持久化到磁盘。

　 这么说吧，redolog 考虑的主要是大量的写的到来，直接顺序的写到redolog里面速度快且持久化过，有保证，其实这个数据页如果在内存里面，以后查询直接读取，如果不在且上面的写没有唯一索引时（没有唯一索引，那就把数据修改加到changbuff里面，在写入redolog，减少读取数据到内存的麻烦）那就把数据页读取出来，和changgbuffer来个merge。当内存不够时，需要把一部分磁盘页刷新到磁盘。完成持久化哦。同时当redolog满了时，也会把一部分内存数据页刷新到磁盘。而刷数据页到磁盘，会导致mysql系统卡顿。

2阶段提交

　　redolog,binlog保持强一致性。一起成功，或者一起失败。不然可能导致数据出现问题。

一个更新语句的执行过程

　　１．先判断该数据对应的数据页是否在内存里面，如是在，则取出对应数据，若是不在，则从磁盘取出该数据页放入内存，并取出该数据。

　　２．修改该数据，且将其更新到内存。

　　３．将其修改更新到redolog里面。且置状态为prepare。

　　４．写入binlog,且将状态改为commit.

mysql 系统抖动

　　１．对于mysql来说，有时候你更新数据很快，有时候会很慢，很慢的时候就是发生了redolog写入磁盘的过程，对于mysql来说，我们的数据要么在内存，要么在磁盘，如果不在磁盘的数据，那么内存的数据是最新的，如果不在内存，那么磁盘的数据是最新的。为什么呢？因为，在redolog写磁盘的一个场景中。当读取量很大的时候，内存不够了，那么我们必须在内存里面淘汰一些数据页。当淘汰的数据页里面，存在脏页（内存和磁盘不匹配）在这种情况下，我们要淘汰磁盘页的同时，把redolog要擦掉的要对应的数据页怼进磁盘里面。以下情况也会使得redolog写数据到磁盘里面。１redolog满了。2系统空闲。3.系统正常关闭。主要分析下，内存不够的情况。对于获取新的数据页，淘汰旧的数据页，我们如果淘汰的全部是脏页，那么性能消耗会大很多，因此我们要保证数据库脏页的比例。
　　innodb_io_capacity，我们通过这个参数去设定。我们通过你的磁盘读写能力来设定这个值的大小。如果设定很低，那么mysql就会默认你的系统很差，如果很高，反之。。。我们系统默认的脏页比例是0.75，我们要控制器脏页比例不能太高。mysql还有一个连坐机制，当发现刷的脏页，旁边也是脏页，那么也会连带清除掉。这对于机械硬盘来说是很大的优化，但是对于ssd来说确实非必要的。

ps：因此当读取数据时，要么从内存里面读取，要么从磁盘读取。