老規(guī)矩，我們還是從一些看似不著邊際的基礎(chǔ)知識開始說起吧徒爹。荚醒。。隆嗅。
操作系統(tǒng)的一些概念
我們常說的磁盤結(jié)構(gòu)圖如下：綠色弧道的就是扇區(qū)界阁，灰色的就是磁道
扇區(qū)是磁盤的最小組成單元，是磁盤的讀寫單位榛瓮，大小我們就機械的認為是512字節(jié)铺董。柱面 就是第一張圖中的磁道磁盤存儲容量 = 磁頭數(shù)磁道（柱面）數(shù)每道扇區(qū)數(shù)每扇區(qū)字節(jié)數(shù)可能有人會發(fā)現(xiàn)，每個扇區(qū)存儲大小一樣禀晓，那豈不是越靠近圓心的扇區(qū)越密集？坝锰？對于老式磁盤確實是粹懒！新式磁盤有所改進，但是我們不打算深究～～～～
磁盤塊（blocks）是操作系統(tǒng)層面的虛擬概念顷级，是操作系統(tǒng)與磁盤打交道的最小單位凫乖，一般是4KB（一般是扇區(qū)大小2^n）頁 是操作系統(tǒng)與內(nèi)存打交道的最小單位
InnoDB中的一些概念
為了顯的高大上，我們也俗套的甩幾個專業(yè)名次上來吧??
Buffer Pool數(shù)據(jù)庫緩沖池
Redo Log 重做日志弓颈，先理解成草稿吧
Datafile 數(shù)據(jù)文件帽芽，先理解成正稿及最終稿吧
Checkpoint,LSN
上面說的這幾個概念都是為了在提升性能的同時，又能保證數(shù)據(jù)不丟失翔冀，那么是怎么做到的呢导街？請看下面一個對比的例子，大家就會明白
互聯(lián)網(wǎng)圈纤子，為了騙取投資人的錢搬瑰，在進行融資前都會編一些ppt啥的款票，老板讓你給他編一個可以忽悠人的ppt，你突然想到一個絕美的idea泽论，但是你白天都在劃水艾少，又不想干活，只想晚上加班搞翼悴，但你又擔心 暫時記在腦子里的這個idea到晚上會忘記缚够，你就會先圍繞這個idea大概思考一個大綱，匆忙記到一個草稿上鹦赎，然后立馬跑到老板面前告訴他潮瓶，你要編什么東東，讓他確認钙姊，到晚上了毯辅，根據(jù)草稿的內(nèi)容去斟詞酌句，編寫正文煞额。正文就是我們最終要拿去騙錢的ppt思恐。
這里我們的大腦就相當于Buffer Pool,我們的大腦就像內(nèi)存一樣記得快，忘的也快膊毁，就像內(nèi)存數(shù)據(jù)易丟失一樣
重做日志Redolog胀莹，就好比我們的草稿
Datafile就是我們的正稿
按照我們編ppt的方式，來進行數(shù)據(jù)庫事務(wù)的寫入操作婚温，不僅能保證數(shù)據(jù)不丟失（大腦忘記了還有草稿）描焰，還能夠快速響應(yīng)，得到客戶端的確認（我們快速給老板響應(yīng)告訴他寫什么栅螟，得到他的確認）
數(shù)據(jù)庫為了保證這個 【草稿】一定能恢復(fù)成正稿荆秦，還不能占用太多空間，就要求這個redo log（草稿）必須具有幾個特點
Redo log一定要保存了所有要寫入的內(nèi)容
Redolog 只會在文件末尾增加數(shù)據(jù)力图，而不會去改變舊的數(shù)據(jù)
一旦事務(wù)數(shù)據(jù)被寫入datafile步绸，redo log中的草稿就可以刪除了
正文在形成之前，草稿是不會刪除的吃媒；也就是說只要草稿在我們一定能寫出正文瓤介，就算數(shù)據(jù)庫Crash了，只要又redolog我們也不怕赘那。
我們知道刑桑，數(shù)據(jù)庫在使用過程中事務(wù)是源源不斷的，也是很快的募舟，而且根據(jù)草稿寫出正稿是一個很費時間的時祠斧，所以往往草稿的產(chǎn)生速度是遠遠大于正稿的產(chǎn)生速度的，也就是說你加班一個晚上根本寫不完胃珍，要連續(xù)寫好多次才有可能寫完梁肿。 這樣就會面臨一個問題蜓陌，昨天我編到哪里了？當然你也可以一個個去對吩蔑，但是這樣效率也太低了吧钮热。 你或許會把最后一條生成正稿的草稿 打上一個標記，這樣第二天可以直接從這個標記的地方開始寫烛芬，而不關(guān)心前面的內(nèi)容隧期，也可以把前面的草稿內(nèi)容刪除掉。
這里最近一條變成正稿的草稿記錄就是Checkpoint,LSN就是每條草稿的編號赘娄。
數(shù)據(jù)庫配置文件匯總
木有辦法仆潮，為了講解innodb的某些東西，我不得不先拐個彎遣臼，把mysql配置吃透～～～
首先我們通過如下命令獲取到mysql服務(wù)的安裝目錄
select @@basedir命令性置。
使用ps aux|grep mysql|grep 'my.cnf' 查看mysql啟動的配置文件，如果沒有揍堰，說明使用的默認配置鹏浅，使用下面的命令
mysql --help|grep 'my.cnf' 啟動時會使用第一個目錄的文件
order of preference, my.cnf, $MYSQL_TCP_PORT,
/etc/my.cnf /etc/mysql/my.cnf /usr/etc/my.cnf ~/.my.cnf
啟動服務(wù) mysqld start 重啟服務(wù)mysqld restart 停止服務(wù) mysqld stop
現(xiàn)在我們知道了如何查找配置文件，已經(jīng)如何啟動服務(wù)（其它更詳細的命令后續(xù)用到了再說）屏歹，終于開始正兒八經(jīng)研究配置文件了
- 數(shù)據(jù)庫配置文件匯總
// 這個是官方的默認文件隐砸，我們按照自己的學(xué)習(xí)記錄一步一步去填充吧。在后續(xù)的概念講解中蝙眶，我們會不時的翻到這個配置文件中來做說明
/*對mysql服務(wù)器的優(yōu)化參數(shù)主要集中在mysqld段中國季希，其它段的參數(shù)對mysql性能的影響微乎其微*/
[mysqld]
# 開啟innodb引擎的獨立表空間MySQL5.6.7之后默認開啟
innodb_file_per_table = 1
# Remove leading # and set to the amount of RAM for the most important data
# cache in MySQL. Start at 70% of total RAM for dedicated server, else 10%.
# innodb_buffer_pool_size = 128M
# Remove leading # to turn on a very important data integrity option: logging
# changes to the binary log between backups.
# log_bin
# These are commonly set, remove the # and set as required.
# basedir = .....
# datadir = .....
# port = .....
# server_id = .....
# socket = .....
# Remove leading # to set options mainly useful for reporting servers.
# The server defaults are faster for transactions and fast SELECTs.
# Adjust sizes as needed, experiment to find the optimal values.
# join_buffer_size = 128M
# sort_buffer_size = 2M
# read_rnd_buffer_size = 2M
sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES
-
表空間：即存放數(shù)據(jù)庫表數(shù)據(jù)的地方
表空間的具體數(shù)據(jù)結(jié)構(gòu)我們后續(xù)講，先搞明白這個表空間是干什么用的幽纷，在看原理式塌。
Innodb有兩種管理表空間的方法：
1．共享表空間（這個我們暫時不研究）
2．獨立表空間每一個表有一個獨立的表空間（現(xiàn)在都用這個，隨著我們講解的進行霹崎，好處自然而然會出來）
如果想要使用獨立表空間珊搀，my.conf中配置innodb_file_per_table【請參照配置文件】
使用命令 show VARIABLES like 'innodb_file_per_table'; 查看獨立表空間是否開啟
開啟該功能后，每創(chuàng)建一個新表就會在數(shù)據(jù)存放目錄中的相應(yīng)庫目錄下面(我的是/var/lib/mysql尾菇，這個目錄可以通過上文截圖中的--datadir=/var/lib/mysql找到)增加一個ibd文件，ibd文件就是該數(shù)據(jù)表的數(shù)據(jù)文件了囚枪。
這個目錄下派诬，每個表都會對應(yīng)一個.frm 文件和一個 .ibd文件，其中.frm是表結(jié)構(gòu)文件链沼，.ibd 是數(shù)據(jù)文件默赂。其中.frm文件是每個存儲引擎都會有的一個文件。
.ibd文件
innodeb引擎括勺，使用IOT（索引組織表缆八，即表中的數(shù)據(jù)都是根據(jù)主鍵順序組織存放）的形式來管理表數(shù)據(jù)曲掰，表的索引跟數(shù)據(jù)都保存在.ibd文件中
既然說到了索引，我們又要先跑一下題奈辰，看一下InnoDB引擎的索引栏妖，innodb使用是B+樹索引。先從B+樹結(jié)構(gòu)說起吧B樹的一個大概查找思路如下：B數(shù)結(jié)構(gòu)
每個節(jié)點中都是有序碼表奖恰，假如我們要查找9吊趾，首先在第一層查找，因為1<9<35 所以定位到第二層的2-10之間瑟啃，然后定位到第三層论泛，在有序碼表中>8最終找到葉子節(jié)點上（B數(shù)中葉子節(jié)點不保存數(shù)據(jù)），如果找到了葉子節(jié)點上蛹屿，說明該數(shù)據(jù)不存在屁奏。同理找37就可以找到。
innodb表的索引跟數(shù)據(jù)文件是同一個.idb文件错负，innodb使用B+Tree坟瓢，與上圖的區(qū)別是，葉子節(jié)點非空湿颅，頁節(jié)點的data域保存了完整的數(shù)據(jù)記錄载绿，碼值域就是數(shù)據(jù)表的主鍵。這種索引與數(shù)據(jù)文件在一塊的就是聚集索引油航。innodb表的輔助索引也是先找到對應(yīng)的主索引崭庸，然后再根據(jù)主索引找到數(shù)據(jù)data這是因為innodb表的數(shù)據(jù)是按照主鍵聚集的，這也同時要求innodb表必須有主鍵
單獨表空間優(yōu)點和缺點
優(yōu)點
每個表都有自已獨立的表空間谊囚。
每個表的數(shù)據(jù)和索引都會存在自已的表空間中怕享。
可以實現(xiàn)單表在不同的數(shù)據(jù)庫中移動。
空間可以回收
缺點
1單表增加過大镰踏，響應(yīng)也是較慢函筋，可以使用分區(qū)表
2單表增加過大，當單表占用空間過大時奠伪，存儲空間不足跌帐，只能從操作系統(tǒng)層面思考解決方法
