## 綜述
在[前一篇](http://mysql.taobao.org/monthly/2016/02/01/)我們介紹了InnoDB文件系統的物理結構,本篇我們繼續介紹InnoDB文件系統的IO接口和內存管理。
為了管理磁盤文件的讀寫操作,InnoDB設計了一套文件IO操作接口,提供了同步IO和異步IO兩種文件讀寫方式。針對異步IO,支持兩種方式:一種是Native AIO,這需要你在編譯階段加上LibAio的Dev包,另外一種是simulated aio模式,InnoDB早期實現了一套系統來模擬異步IO,但現在Native Aio已經很成熟了,并且Simulated Aio本身存在性能問題,建議生產環境開啟Native Aio模式。
對于數據讀操作,通常用戶線程觸發的數據塊請求讀是同步讀,如果開啟了數據預讀機制的話,預讀的數據塊則為異步讀,由后臺IO線程進行。其他后臺線程也會觸發數據讀操作,例如Purge線程在無效數據清理,會讀undo頁和數據頁;Master線程定期做ibuf merge也會讀入數據頁。崩潰恢復階段也可能觸發異步讀來加速recover的速度。
對于數據寫操作,InnoDB和大部分數據庫系統一樣,都是WAL模式,即先寫日志,延遲寫數據頁。事務日志的寫入通常在事務提交時觸發,后臺master線程也會每秒做一次redo fsync。數據頁則通常由后臺Page cleaner線程觸發。但當buffer pool空閑block不夠時,或者沒做checkpoint的lsn age太長時,也會驅動刷臟操作,這兩種場景由用戶線程來觸發。Percona Server據此做了優化來避免用戶線程參與。MySQL5.7也對應做了些不一樣的優化。
除了數據塊操作,還有物理文件級別的操作,例如truncate、drop table、rename table等DDL操作,InnoDB需要對這些操作進行協調,目前的解法是通過特殊的flag和計數器的方式來解決。
當文件讀入內存后,我們需要一種統一的方式來對數據進行管理,在啟動實例時,InnoDB會按照instance分區分配多個一大塊內存(在5.7里則是按照可配置的chunk size進行內存塊劃分),每個chunk又以UNIV_PAGE_SIZE為單位進行劃分。數據讀入內存時,會從buffer pool的free list中分配一個空閑block。所有的數據頁都存儲在一個LRU鏈表上,修改過的block被加到`flush_list`上,解壓的數據頁被放到unzip_LRU鏈表上。我們可以配置buffer pool為多個instance,以降低對鏈表的競爭開銷。
在關鍵的地方本文注明了代碼函數,建議讀者邊參考代碼邊閱讀本文,本文的代碼部分基于MySQL 5.7.11版本,不同的版本函數名或邏輯可能會有所不同。請讀者閱讀本文時盡量選擇該版本的代碼。
## IO子系統
本小節我們介紹下磁盤文件與內存數據的中樞,即IO子系統。InnoDB對page的磁盤操作分為讀操作和寫操作。
對于讀操作,在將數據讀入磁盤前,總是為其先預先分配好一個block,然后再去磁盤讀取一個新的page,在使用這個page之前,還需要檢查是否有change buffer項,并根據change buffer進行數據變更。讀操作分為兩種場景:普通的讀page及預讀操作,前者為同步讀,后者為異步讀
數據寫操作也分為兩種,一種是batch write,一種是single page write。寫page默認受double write buffer保護,因此對double write buffer的寫磁盤為同步寫,而對數據文件的寫入為異步寫。
同步讀寫操作通常由用戶線程來完成,而異步讀寫操作則需要后臺線程的協同。
舉個簡單的例子,假設我們向磁盤批量寫數據,首先先寫到double write buffer,當dblwr滿了之后,一次性將dblwr中的數據同步刷到ibdata,在確保sync到dblwr后,再將這些page分別異步寫到各自的文件中。注意這時候dblwr依舊未被清空,新的寫Page請求會進入等待。當異步寫page完成后,io helper線程會調用`buf_flush_write_complete`,將寫入的Page從flush list上移除。當dblwr中的page完全寫完后,在函數`buf_dblwr_update`里將dblwr清空。這時候才允許新的寫請求進dblwr。
同樣的,對于異步寫操作,也需要IO Helper線程來檢查page是否完好、merge change buffer等一系列操作。
除了數據頁的寫入,還包括日志異步寫入線程、及ibuf后臺線程。
### IO后臺線程
InnoDB的IO后臺線程主要包括如下幾類:
* IO READ 線程:后臺讀線程,線程數目通過參數`innodb_read_io_threads`配置,主要處理INNODB 數據文件異步讀請求,任務隊列為`AIO::s_reads`,任務隊列包含slot數為線程數 * 256(linux 平臺),也就是說,每個read線程最多可以pend 256個任務;
* IO WRITE 線程:后臺寫線程數,線程數目通過參數`innodb_write_io_threads`配置。主要處理INNODB 數據文件異步寫請求,任務隊列為`AIO::s_writes`,任務隊列包含slot數為線程數 * 256(linux 平臺),也就是說,每個read線程最多可以pend 256個任務;
* LOG 線程:寫日志線程。只有在寫checkpoint信息時才會發出一次異步寫請求。任務隊列為`AIO::s_log`,共1個segment,包含256個slot;
* IBUF 線程:負責讀入change buffer頁的后臺線程,任務隊列為`AIO::s_ibuf`,共1個segment,包含256個slot
所有的同步寫操作都是由用戶線程或其他后臺線程執行。上述IO線程只負責異步操作。
### 發起IO請求
入口函數:`os_aio_func`
首先對于同步讀寫請求(`OS_AIO_SYNC`),發起請求的線程直接調用`os_file_read_func`?或者`os_file_write_func`?去讀寫文件,然后返回。
對于異步請求,用戶線程從對應操作類型的任務隊列(`AIO::select_slot_array`)中選取一個slot,將需要讀寫的信息存儲于其中(`AIO::reserve_slot`):
1. 首先在任務隊列數組中選擇一個segment;這里根據偏移量來算segment,因此可以盡可能的將相鄰的讀寫請求放到一起,這有利于在IO層的合并操作
~~~
local_seg = (offset >> (UNIV_PAGE_SIZE_SHIFT + 6)) % m_n_segments;
~~~
2. 從該segment范圍內選擇一個空閑的slot,如果沒有則等待;
3. 將對應的文件讀寫請求信息賦值到slot中,例如寫入的目標文件,偏移量,數據等;
4. 如果這是一次IO寫入操作,且使用native aio時,如果表開啟了transparent compression,則對要寫入的數據頁先進行壓縮并punch hole;如果設置了表空間加密,再對數據頁進行加密;
對于Native AIO(使用linux自帶的LIBAIO庫),調用函數`AIO::linux_dispatch`,將IO請求分發給kernel層。
如果沒有開啟Native AIO,且沒有設置wakeup later 標記,則會去喚醒io線程(`AIO::wake_simulated_handler_thread`),這是早期libaio還不成熟時,InnoDB在內部模擬aio實現的邏輯。
Tips:編譯Native AIO需要安裝libaio-dev包,并打開選項`srv_use_native_aio`。
### 處理異步AIO請求
IO線程入口函數為`io_handler_thread --> fil_aio_wait`
首先調用`os_aio_handler`來獲取請求:
1. 對于Native AIO,調用函數`os_aio_linux_handle`?獲取讀寫請求。IO線程會反復以500ms(`OS_AIO_REAP_TIMEOUT`)的超時時間通過io_getevents確認是否有任務已經完成了(`LinuxAIOHandler::collect()`),如果有讀寫任務完成,找到已完成任務的slot后,釋放對應的槽位;
2. 對于simulated aio,調用函數`os_aio_simulated_handler`?處理讀寫請求,這里相比NATIVE AIO要復雜很多;
* 如果這是異步讀隊列,并且`os_aio_recommend_sleep_for_read_threads`被設置,則暫時不處理,而是等待一會,讓其他線程有機會將更過的IO請求發送過來。目前linear readhaed 會使用到該功能。這樣可以得到更好的IO合并效果(`SimulatedAIOHandler::check_pending`);
* 已經完成的slot需要及時被處理(`SimulatedAIOHandler::check_completed`,可能由上次的io合并操作完成);
* 如果有超過2秒未被調度的請求(`SimulatedAIOHandler::select_oldest`),則優先選擇最老的slot,防止餓死,否則,找一個文件讀寫偏移量最小的位置的slot(`SimulatedAIOHandler::select()`);
* 沒有任何請求時進入等待狀態;
* 當找到一個未完成的slot時,會嘗試merge相鄰的IO請求(`SimulatedAIOHandler::merge()`),并將對應的slot加入到`SimulatedAIOHandler::m_slots`數組中,最多不超過64個slot;
* 然而在5.7版本里,合并操作已經被禁止了,全部改成了一個個slot進行讀寫,升級到5.7的用戶一定要注意這個改變,或者改為使用更好的Native AIO方式;
* 完成io后,釋放slot; 并選擇第一個處理完的slot作為隨后優先完成的請求。
從上一步獲得完成IO的slot后,調用函數`fil_node_complete_io`, 遞減`node->n_pending`。對于文件寫操作,需要加入到`fil_system->unflushed_spaces`鏈表上,表示這個文件修改過了,后續需要被sync到磁盤。
如果設置為`O_DIRECT_NO_FSYNC`的文件IO模式,則數據文件無需加入到`fil_system_t::unflushed_spaces`鏈表上。通常我們即時使用`O_DIRECT`的方式操作文件,也需要做一次sync,來保證文件元數據的持久化,但在某些文件系統下則沒有這個必要,通常只要文件的大小這些關鍵元數據沒發生變化,可以省略一次fsync。
最后在IO完成后,調用`buf_page_io_complete`,做page corruption檢查、change buffer merge等操作;對于寫操作,需要從flush list上移除block并更新double write buffer;對于LRU FLUSH產生的寫操作,還會將其對應的block釋放到free list上;
對于日志文件操作,調用`log_io_complete`執行一次fil_flush,并更新內存內的checkpoint信息(`log_complete_checkpoint`)。
### IO 并發控制
由于文件底層使用pwrite/pread來進行文件I/O,因此用戶線程對文件普通的并發I/O操作無需加鎖。但在windows平臺下,則需要加鎖進行讀寫。
對相同文件的IO操作通過大量的counter/flag來進行并發控制。
當文件處于擴展階段時(`fil_space_extend`),將`fil_node_t::being_extended`設置為true,避免產生并發Extent,或其他關閉文件或者rename操作等。
當正在刪除一個表時,會檢查是否有pending的操作(`fil_check_pending_operations`)。
1. 將`fil_space_t::stop_new_ops`設置為true;
2. 檢查是否有Pending的change buffer merge (`fil_space_t::n_pending_ops`);有則等待;
3. 檢查是否有pending的IO(`fil_node_t::n_pending`) 或者pending的文件flush操作(`fil_node_t::n_pending_flushes`);有則等待。
當truncate一張表時,和drop table類似,也會調用函數`fil_check_pending_operations`,檢查表上是否有pending的操作,并將`fil_space_t::is_being_truncated`設置為true。
當rename一張表時(`fil_rename_tablespace`),將文件的stop_ios標記設置為true,阻止其他線程所有的I/O操作。
當進行文件讀寫操作時,如果是異步讀操作,發現`stop_new_ops`或者被設置了但`is_being_truncated`未被設置,會返回報錯;但依然允許同步讀或異步寫操作(`fil_io`)。
當進行文件flush操作時,如果發現`fil_space_t::stop_new_ops`或者`fil_space_t::is_being_truncated`被設置了,則忽略該文件的flush操作 (`fil_flush_file_spaces`)。
### 文件預讀
文件預讀是一項在SSD普及前普通磁盤上比較常見的技術,通過預讀的方式進行連續IO而非帶價高昂的隨機IO。InnoDB有兩種預讀方式:隨機預讀及線性預讀;Facebook另外還實現了一種邏輯預讀的方式。
隨機預讀
入口函數:`buf_read_ahead_random`
以64個Page為單位(這也是一個Extent的大小),當前讀入的page no所在的64個pagno 區域[ (page_no/64)*64, (page_no/64) *64 + 64],如果最近被訪問的Page數超過`BUF_READ_AHEAD_RANDOM_THRESHOLD`(通常值為13),則將其他Page也讀進內存。這里采取異步讀。
隨機預讀受參數`innodb_random_read_ahead`控制
線性預讀
入口函數:`buf_read_ahead_linear`
所謂線性預讀,就是在讀入一個新的page時,和隨機預讀類似的64個連續page范圍內,默認從低到高Page no,如果最近連續被訪問的page數超過`innodb_read_ahead_threshold`,則將該Extent之后的其他page也讀取進來。
邏輯預讀
由于表可能存在碎片空間,因此很可能對于諸如全表掃描這樣的場景,連續讀取的page并不是物理連續的,線性預讀不能解決這樣的問題,另外一次讀取一個Extent對于需要全表掃描的負載并不足夠。因此Facebook引入了邏輯預讀。
其大致思路為,掃描聚集索引,搜集葉子節點號,然后根據葉子節點的page no (可以從非葉子節點獲取)順序異步讀入一定量的page。
由于Innodb Aio一次只支持提交一個page讀請求,雖然Kernel層本身會做讀請求合并,但那顯然效率不夠高。他們對此做了修改,使INNODB可以支持一次提交(`io_submit`)多個aio請求。
入口函數:`row_search_for_mysql --> row_read_ahead_logical`
具體參閱[這篇博文](http://planet.mysql.com/entry/?id=516236)
或者webscalesql上的幾個commit:
~~~
git show 2d61329446a08f85c89a4119317ae85baacf2bbb // 合并多個AIO請求,對所有的預讀邏輯(上述三種)采用這種方式
git show 9f52bfd2222403f841fe5fcbedd1333f78a70a4b // 邏輯預讀的主要代碼邏輯
git show 64b68e07430b50f6bff5ed67374b336623db24b6 // 防止事務在多個表上讀取操作時預讀帶來的影響
~~~
### 日志填充寫入
由于現代磁盤通常的block size都是大于512字節的,例如一般是4096字節,為了避免 “read-on-write” 問題,在5.7版本里添加了一個參數`innodb_log_write_ahead_size`,你可以通過配置該參數,在寫入redo log時,將寫入區域配置到block size對齊的字節數。
在代碼里的實現,就是在寫入redo log 文件之前,為尾部字節填充0(參考函數`log_write_up_to`)。
Tips:所謂READ-ON-WRITE問題,就是當修改的字節不足一個block時,需要將整個block讀進內存,修改對應的位置,然后再寫進去;如果我們以block為單位來寫入的話,直接完整覆蓋寫入即可。
## buffer pool 內存管理
InnoDB buffer pool從5.6到5.7版本發生了很大的變化。首先是分配方式上不同,其次實現了更好的刷臟效率。對buffer pool上的各個鏈表的管理也更加高效。
### buffer pool初始化
在5.7之前的版本中,一個buffer pool instance擁有一個chunk,每個chunk的大小為buffer pool size / instance個數。
而到了5.7版本中,每個instance可能劃分成多個chunk,每個chunk的大小是可定義的,默認為127MB。因此一個buffer pool instance可能包含多個chunk內存塊。這么做的目的是為了實現在線調整buffer pool大小([WL#6117](http://dev.mysql.com/worklog/task/?id=6117)),buffer pool增加或減少必須以chunk為基本單位進行。
在5.7里有個問題值得關注,即buffer pool size會根據instances * chunk size向上對齊,舉個簡單的例子,假設你配置了64個instance, chunk size為默認128MB,就需要以8GB進行對齊,這意味著如果你配置了9GB的buffer pool,實際使用的會是16GB。所以盡量不要配置太多的buffer pool instance。
### buffer pool 鏈表及管理對象
出于不同的目的,每個buffer pool instance上都維持了多個鏈表,可以根據space id及page no找到對應的instance(`buf_pool_get`)。
一些關鍵的結構對象及描述如下表所示:
| name | desc |
| --- | --- |
| buf_pool_t::page_hash | page_hash用于存儲已經或正在讀入內存的page。根據快速查找。當不在page hash時,才會去嘗試從文件讀取 |
| buf_pool_t::LRU | LRU上維持了所有從磁盤讀入的數據頁,該LRU上又在鏈表尾部開始大約3/8處將鏈表劃分為兩部分,新讀入的page被加入到這個位置;當我們設置了innodb_old_blocks_time,若兩次訪問page的時間超過該閥值,則將其挪動到LRU頭部;這就避免了類似一次性的全表掃描操作導致buffer pool污染 |
| buf_pool_t::free | 存儲了當前空閑可分配的block |
| buf_pool_t::flush_list | 存儲了被修改過的page,根據oldest_modification(即載入內存后第一次修改該page時的Redo LSN)排序 |
| buf_pool_t::flush_rbt | 在崩潰恢復階段在flush list上建立的紅黑數,用于將apply redo后的page快速的插入到flush list上,以保證其有序 |
| buf_pool_t::unzip_LRU | 壓縮表上解壓后的page被存儲到unzip_LRU。 buf_block_t::frame存儲解壓后的數據,buf_block_t::page->zip.data指向原始壓縮數據。 |
| buf_pool_t::zip_free[BUF_BUDDY_SIZES_MAX] | 用于管理壓縮頁產生的空閑碎片page。壓縮頁占用的內存采用buddy allocator算法進行分配。 |
### buffer pool 并發控制
除了不同的用戶線程會并發操作buffer pool外,還有后臺線程也會對buffer pool進行操作。InnoDB通過讀寫鎖、buf fix計數、io fix標記來進行并發控制。
讀寫并發控制
通常當我們讀取到一個page時,會對其加block S鎖,并遞增`buf_page_t::buf_fix_count`,直到mtr commit時才會恢復。而如果讀page的目的是為了進行修改,則會加X鎖。
當一個page準備flush到磁盤時(`buf_flush_page`),如果當前Page正在被訪問,其`buf_fix_count`不為0時,就忽略flush該page,以減少獲取block上SX Lock的昂貴代價。
并發讀控制
當多個線程請求相同的page時,如果page不在內存,是否可能引發對同一個page的文件IO ?答案是不會。
從函數`buf_page_init_for_read`我們可以看到,在準備讀入一個page前,會做如下工作:
1. 分配一個空閑block;
2. `buf_pool_mutex_enter`;
3. 持有page_hash x lock;
4. 檢查page_hash中是否已被讀入,如果是,表示另外一個線程已經完成了io,則忽略本次io請求,退出;
5. 持有`block->mutex`,對block進行初始化,并加入到page hash中;
6. 設置IO FIX為`BUF_IO_READ`;
7. 釋放hash lock;
8. 將block加入到LRU上;
9. 持有block s lock;
10. 完成IO后,釋放s lock;
當另外一個線程也想請求相同page時,首先如果看到page hash中已經有對應的block了,說明page已經或正在被讀入buffer pool,如果`io_fix`為`BUF_IO_READ`,說明正在進行IO,就通過加X鎖的方式做一次sync(`buf_wait_for_read`),確保IO完成。
請求Page通常還需要加S或X鎖,而IO期間也是持有block x鎖的,如果成功獲取了鎖,說明IO肯定完成了。
### Page驅逐及刷臟
當buffer pool中的free list不足時,為了獲取一個空閑block,通常會觸發page驅逐操作(`buf_LRU_free_from_unzip_LRU_list`)。
首先由于壓縮頁在內存中可能存在兩份拷貝:壓縮頁和解壓頁;InnoDB根據最近的IO情況和數據解壓技術來判定實例是處于IO-BOUND還是CPU-BOUND(`buf_LRU_evict_from_unzip_LRU`)。如果是IO-BOUND的話,就嘗試從unzip_lru上釋放一個block出來(`buf_LRU_free_from_unzip_LRU_list`),而壓縮頁依舊保存在內存中。
其次再考慮從`buf_pool_t::LRU`鏈表上釋放block,如果有可替換的page(`buf_flush_ready_for_replace`)時,則將其釋放掉,并加入到free list上;對于壓縮表,壓縮頁和解壓頁在這里都會被同時驅逐。
當無法從LRU上獲得一個可替換的Page時,說明當前Buffer pool可能存在大量臟頁,這時候會觸發single page flush(`buf_flush_single_page_from_LRU`),即用戶線程主動去刷一個臟頁并替換掉。這是個慢操作,尤其是如果并發很高的時候,可能觀察到系統的性能急劇下降。在RDS MySQL中,我們開啟了一個后臺線程, 能夠自動根據當前Free List的長度來主動做flush,避免用戶線程陷入其中。
除了single page flush外,在MySQL 5.7版本里還引入了多個page cleaner線程,根據一定的啟發式算法,可以定期且高效的的做page flush操作。
- 數據庫內核月報目錄
- 數據庫內核月報 - 2016/09
- MySQL · 社區貢獻 · AliSQL那些事兒
- PetaData · 架構體系 · PetaData第二代低成本存儲體系
- MySQL · 社區動態 · MariaDB 10.2 前瞻
- MySQL · 特性分析 · 執行計劃緩存設計與實現
- PgSQL · 最佳實踐 · pg_rman源碼淺析與使用
- MySQL · 捉蟲狀態 · bug分析兩例
- PgSQL · 源碼分析 · PG優化器淺析
- MongoDB · 特性分析· Sharding原理與應用
- PgSQL · 源碼分析 · PG中的無鎖算法和原子操作應用一則
- SQLServer · 最佳實踐 · TEMPDB的設計
- 數據庫內核月報 - 2016/08
- MySQL · 特性分析 ·MySQL 5.7新特性系列四
- PgSQL · PostgreSQL 邏輯流復制技術的秘密
- MySQL · 特性分析 · MyRocks簡介
- GPDB · 特性分析· Greenplum 備份架構
- SQLServer · 最佳實踐 · RDS for SQLServer 2012權限限制提升與改善
- TokuDB · 引擎特性 · REPLACE 語句優化
- MySQL · 專家投稿 · InnoDB物理行中null值的存儲的推斷與驗證
- PgSQL · 實戰經驗 · 旋轉門壓縮算法在PostgreSQL中的實現
- MySQL · 源碼分析 · Query Cache并發處理
- PgSQL · 源碼分析· pg_dump分析
- 數據庫內核月報 - 2016/07
- MySQL · 特性分析 ·MySQL 5.7新特性系列三
- MySQL · 特性分析 · 5.7 代價模型淺析
- PgSQL · 實戰經驗 · 分組TOP性能提升44倍
- MySQL · 源碼分析 · 網絡通信模塊淺析
- MongoDB · 特性分析 · 索引原理
- SQLServer · 特性分析 · XML與JSON應用比較
- MySQL · 最佳實戰 · 審計日志實用案例分析
- MySQL · 性能優化 · 條件下推到物化表
- MySQL · 源碼分析 · Query Cache內部剖析
- MySQL · 捉蟲動態 · 備庫1206錯誤問題說明
- 數據庫內核月報 - 2016/06
- MySQL · 特性分析 · innodb 鎖分裂繼承與遷移
- MySQL · 特性分析 ·MySQL 5.7新特性系列二
- PgSQL · 實戰經驗 · 如何預測Freeze IO風暴
- GPDB · 特性分析· Filespace和Tablespace
- MariaDB · 新特性 · 窗口函數
- MySQL · TokuDB · checkpoint過程
- MySQL · 特性分析 · 內部臨時表
- MySQL · 最佳實踐 · 空間優化
- SQLServer · 最佳實踐 · 數據庫實現大容量插入的幾種方式
- 數據庫內核月報 - 2016/05
- MySQL · 引擎特性 · 基于InnoDB的物理復制實現
- MySQL · 特性分析 · MySQL 5.7新特性系列一
- PostgreSQL · 特性分析 · 邏輯結構和權限體系
- MySQL · 特性分析 · innodb buffer pool相關特性
- PG&GP · 特性分析 · 外部數據導入接口實現分析
- SQLServer · 最佳實踐 · 透明數據加密在SQLServer的應用
- MySQL · TokuDB · 日志子系統和崩潰恢復過程
- MongoDB · 特性分析 · Sharded cluster架構原理
- PostgreSQL · 特性分析 · 統計信息計算方法
- MySQL · 捉蟲動態 · left-join多表導致crash
- 數據庫內核月報 - 2016/04
- MySQL · 參數故事 · innodb_additional_mem_pool_size
- GPDB · 特性分析 · Segment事務一致性與異常處理
- GPDB · 特性分析 · Segment 修復指南
- MySQL · 捉蟲動態 · 并行復制外鍵約束問題二
- PgSQL · 性能優化 · 如何瀟灑的處理每天上百TB的數據增量
- Memcached · 最佳實踐 · 熱點 Key 問題解決方案
- MongoDB · 最佳實踐 · 短連接Auth性能優化
- MySQL · 最佳實踐 · RDS 只讀實例延遲分析
- MySQL · TokuDB · TokuDB索引結構--Fractal Tree
- MySQL · TokuDB · Savepoint漫談
- 數據庫內核月報 - 2016/03
- MySQL · TokuDB · 事務子系統和 MVCC 實現
- MongoDB · 特性分析 · MMAPv1 存儲引擎原理
- PgSQL · 源碼分析 · 優化器邏輯推理
- SQLServer · BUG分析 · Agent 鏈接泄露分析
- Redis · 特性分析 · AOF Rewrite 分析
- MySQL · BUG分析 · Rename table 死鎖分析
- MySQL · 物理備份 · Percona XtraBackup 備份原理
- GPDB · 特性分析· GreenPlum FTS 機制
- MySQL · 答疑解惑 · 備庫Seconds_Behind_Master計算
- MySQL · 答疑解惑 · MySQL 鎖問題最佳實踐
- 數據庫內核月報 - 2016/02
- MySQL · 引擎特性 · InnoDB 文件系統之文件物理結構
- MySQL · 引擎特性 · InnoDB 文件系統之IO系統和內存管理
- MySQL · 特性分析 · InnoDB transaction history
- PgSQL · 會議見聞 · PgConf.Russia 2016 大會總結
- PgSQL · 答疑解惑 · PostgreSQL 9.6 并行查詢實現分析
- MySQL · TokuDB · TokuDB之黑科技工具
- PgSQL · 性能優化 · PostgreSQL TPC-C極限優化玩法
- MariaDB · 版本特性 · MariaDB 的 GTID 介紹
- MySQL · 特性分析 · 線程池
- MySQL · 答疑解惑 · mysqldump tips 兩則
- 數據庫內核月報 - 2016/01
- MySQL · 引擎特性 · InnoDB 事務鎖系統簡介
- GPDB · 特性分析· GreenPlum Primary/Mirror 同步機制
- MySQL · 專家投稿 · MySQL5.7 的 JSON 實現
- MySQL · 特性分析 · 優化器 MRR & BKA
- MySQL · 答疑解惑 · 物理備份死鎖分析
- MySQL · TokuDB · Cachetable 的工作線程和線程池
- MySQL · 特性分析 · drop table的優化
- MySQL · 答疑解惑 · GTID不一致分析
- PgSQL · 特性分析 · Plan Hint
- MariaDB · 社區動態 · MariaDB on Power8 (下)
- 數據庫內核月報 - 2015/12
- MySQL · 引擎特性 · InnoDB 事務子系統介紹
- PgSQL · 特性介紹 · 全文搜索介紹
- MongoDB · 捉蟲動態 · Kill Hang問題排查記錄
- MySQL · 參數優化 ·RDS MySQL參數調優最佳實踐
- PgSQL · 特性分析 · 備庫激活過程分析
- MySQL · TokuDB · 讓Hot Backup更完美
- PgSQL · 答疑解惑 · 表膨脹
- MySQL · 特性分析 · Index Condition Pushdown (ICP)
- MariaDB · 社區動態 · MariaDB on Power8
- MySQL · 特性分析 · 企業版特性一覽
- 數據庫內核月報 - 2015/11
- MySQL · 社區見聞 · OOW 2015 總結 MySQL 篇
- MySQL · 特性分析 · Statement Digest
- PgSQL · 答疑解惑 · PostgreSQL 用戶組權限管理
- MySQL · 特性分析 · MDL 實現分析
- PgSQL · 特性分析 · full page write 機制
- MySQL · 捉蟲動態 · MySQL 外鍵異常分析
- MySQL · 答疑解惑 · MySQL 優化器 range 的代價計算
- MySQL · 捉蟲動態 · ORDER/GROUP BY 導致 mysqld crash
- MySQL · TokuDB · TokuDB 中的行鎖
- MySQL · 捉蟲動態 · order by limit 造成優化器選擇索引錯誤
- 數據庫內核月報 - 2015/10
- MySQL · 引擎特性 · InnoDB 全文索引簡介
- MySQL · 特性分析 · 跟蹤Metadata lock
- MySQL · 答疑解惑 · 索引過濾性太差引起CPU飆高分析
- PgSQL · 特性分析 · PG主備流復制機制
- MySQL · 捉蟲動態 · start slave crash 診斷分析
- MySQL · 捉蟲動態 · 刪除索引導致表無法打開
- PgSQL · 特性分析 · PostgreSQL Aurora方案與DEMO
- TokuDB · 捉蟲動態 · CREATE DATABASE 導致crash問題
- PgSQL · 特性分析 · pg_receivexlog工具解析
- MySQL · 特性分析 · MySQL權限存儲與管理
- 數據庫內核月報 - 2015/09
- MySQL · 引擎特性 · InnoDB Adaptive hash index介紹
- PgSQL · 特性分析 · clog異步提交一致性、原子操作與fsync
- MySQL · 捉蟲動態 · BUG 幾例
- PgSQL · 答疑解惑 · 詭異的函數返回值
- MySQL · 捉蟲動態 · 建表過程中crash造成重建表失敗
- PgSQL · 特性分析 · 談談checkpoint的調度
- MySQL · 特性分析 · 5.6 并行復制恢復實現
- MySQL · 備庫優化 · relay fetch 備庫優化
- MySQL · 特性分析 · 5.6并行復制事件分發機制
- MySQL · TokuDB · 文件目錄談
- 數據庫內核月報 - 2015/08
- MySQL · 社區動態 · InnoDB Page Compression
- PgSQL · 答疑解惑 · RDS中的PostgreSQL備庫延遲原因分析
- MySQL · 社區動態 · MySQL5.6.26 Release Note解讀
- PgSQL · 捉蟲動態 · 執行大SQL語句提示無效的內存申請大小
- MySQL · 社區動態 · MariaDB InnoDB表空間碎片整理
- PgSQL · 答疑解惑 · 歸檔進程cp命令的core文件追查
- MySQL · 答疑解惑 · open file limits
- MySQL · TokuDB · 瘋狂的 filenum++
- MySQL · 功能分析 · 5.6 并行復制實現分析
- MySQL · 功能分析 · MySQL表定義緩存
- 數據庫內核月報 - 2015/07
- MySQL · 引擎特性 · Innodb change buffer介紹
- MySQL · TokuDB · TokuDB Checkpoint機制
- PgSQL · 特性分析 · 時間線解析
- PgSQL · 功能分析 · PostGIS 在 O2O應用中的優勢
- MySQL · 引擎特性 · InnoDB index lock前世今生
- MySQL · 社區動態 · MySQL內存分配支持NUMA
- MySQL · 答疑解惑 · 外鍵刪除bug分析
- MySQL · 引擎特性 · MySQL logical read-ahead
- MySQL · 功能介紹 · binlog拉取速度的控制
- MySQL · 答疑解惑 · 浮點型的顯示問題
- 數據庫內核月報 - 2015/06
- MySQL · 引擎特性 · InnoDB 崩潰恢復過程
- MySQL · 捉蟲動態 · 唯一鍵約束失效
- MySQL · 捉蟲動態 · ALTER IGNORE TABLE導致主備不一致
- MySQL · 答疑解惑 · MySQL Sort 分頁
- MySQL · 答疑解惑 · binlog event 中的 error code
- PgSQL · 功能分析 · Listen/Notify 功能
- MySQL · 捉蟲動態 · 任性的 normal shutdown
- PgSQL · 追根究底 · WAL日志空間的意外增長
- MySQL · 社區動態 · MariaDB Role 體系
- MySQL · TokuDB · TokuDB數據文件大小計算
- 數據庫內核月報 - 2015/05
- MySQL · 引擎特性 · InnoDB redo log漫游
- MySQL · 專家投稿 · MySQL數據庫SYS CPU高的可能性分析
- MySQL · 捉蟲動態 · 5.6 與 5.5 InnoDB 不兼容導致 crash
- MySQL · 答疑解惑 · InnoDB 預讀 VS Oracle 多塊讀
- PgSQL · 社區動態 · 9.5 新功能BRIN索引
- MySQL · 捉蟲動態 · MySQL DDL BUG
- MySQL · 答疑解惑 · set names 都做了什么
- MySQL · 捉蟲動態 · 臨時表操作導致主備不一致
- TokuDB · 引擎特性 · zstd壓縮算法
- MySQL · 答疑解惑 · binlog 位點刷新策略
- 數據庫內核月報 - 2015/04
- MySQL · 引擎特性 · InnoDB undo log 漫游
- TokuDB · 產品新聞 · RDS TokuDB小手冊
- PgSQL · 社區動態 · 說一說PgSQL 9.4.1中的那些安全補丁
- MySQL · 捉蟲動態 · 連接斷開導致XA事務丟失
- MySQL · 捉蟲動態 · GTID下slave_net_timeout值太小問題
- MySQL · 捉蟲動態 · Relay log 中 GTID group 完整性檢測
- MySQL · 答疑釋惑 · UPDATE交換列單表和多表的區別
- MySQL · 捉蟲動態 · 刪被引用索引導致crash
- MySQL · 答疑釋惑 · GTID下auto_position=0時數據不一致
- 數據庫內核月報 - 2015/03
- MySQL · 答疑釋惑· 并發Replace into導致的死鎖分析
- MySQL · 性能優化· 5.7.6 InnoDB page flush 優化
- MySQL · 捉蟲動態· pid file丟失問題分析
- MySQL · 答疑釋惑· using filesort VS using temporary
- MySQL · 優化限制· MySQL index_condition_pushdown
- MySQL · 捉蟲動態·DROP DATABASE外鍵約束的GTID BUG
- MySQL · 答疑釋惑· lower_case_table_names 使用問題
- PgSQL · 特性分析· Logical Decoding探索
- PgSQL · 特性分析· jsonb類型解析
- TokuDB ·引擎機制· TokuDB線程池
- 數據庫內核月報 - 2015/02
- MySQL · 性能優化· InnoDB buffer pool flush策略漫談
- MySQL · 社區動態· 5.6.23 InnoDB相關Bugfix
- PgSQL · 特性分析· Replication Slot
- PgSQL · 特性分析· pg_prewarm
- MySQL · 答疑釋惑· InnoDB丟失自增值
- MySQL · 答疑釋惑· 5.5 和 5.6 時間類型兼容問題
- MySQL · 捉蟲動態· 變量修改導致binlog錯誤
- MariaDB · 特性分析· 表/表空間加密
- MariaDB · 特性分析· Per-query variables
- TokuDB · 特性分析· 日志詳解
- 數據庫內核月報 - 2015/01
- MySQL · 性能優化· Group Commit優化
- MySQL · 新增特性· DDL fast fail
- MySQL · 性能優化· 啟用GTID場景的性能問題及優化
- MySQL · 捉蟲動態· InnoDB自增列重復值問題
- MySQL · 優化改進· 復制性能改進過程
- MySQL · 談古論今· key分區算法演變分析
- MySQL · 捉蟲動態· mysql client crash一例
- MySQL · 捉蟲動態· 設置 gtid_purged 破壞AUTO_POSITION復制協議
- MySQL · 捉蟲動態· replicate filter 和 GTID 一起使用的問題
- TokuDB·特性分析· Optimize Table
- 數據庫內核月報 - 2014/12
- MySQL· 性能優化·5.7 Innodb事務系統
- MySQL· 踩過的坑·5.6 GTID 和存儲引擎那會事
- MySQL· 性能優化·thread pool 原理分析
- MySQL· 性能優化·并行復制外建約束問題
- MySQL· 答疑釋惑·binlog event有序性
- MySQL· 答疑釋惑·server_id為0的Rotate
- MySQL· 性能優化·Bulk Load for CREATE INDEX
- MySQL· 捉蟲動態·Opened tables block read only
- MySQL· 優化改進· GTID啟動優化
- TokuDB· Binary Log Group Commit with TokuDB
- 數據庫內核月報 - 2014/11
- MySQL· 捉蟲動態·OPTIMIZE 不存在的表
- MySQL· 捉蟲動態·SIGHUP 導致 binlog 寫錯
- MySQL· 5.7改進·Recovery改進
- MySQL· 5.7特性·高可用支持
- MySQL· 5.7優化·Metadata Lock子系統的優化
- MySQL· 5.7特性·在線Truncate undo log 表空間
- MySQL· 性能優化·hash_scan 算法的實現解析
- TokuDB· 版本優化· 7.5.0
- TokuDB· 引擎特性· FAST UPDATES
- MariaDB· 性能優化·filesort with small LIMIT optimization
- 數據庫內核月報 - 2014/10
- MySQL· 5.7重構·Optimizer Cost Model
- MySQL· 系統限制·text字段數
- MySQL· 捉蟲動態·binlog重放失敗
- MySQL· 捉蟲動態·從庫OOM
- MySQL· 捉蟲動態·崩潰恢復失敗
- MySQL· 功能改進·InnoDB Warmup特性
- MySQL· 文件結構·告別frm文件
- MariaDB· 新鮮特性·ANALYZE statement 語法
- TokuDB· 主備復制·Read Free Replication
- TokuDB· 引擎特性·壓縮
- 數據庫內核月報 - 2014/09
- MySQL· 捉蟲動態·GTID 和 DELAYED
- MySQL· 限制改進·GTID和升級
- MySQL· 捉蟲動態·GTID 和 binlog_checksum
- MySQL· 引擎差異·create_time in status
- MySQL· 參數故事·thread_concurrency
- MySQL· 捉蟲動態·auto_increment
- MariaDB· 性能優化·Extended Keys
- MariaDB·主備復制·CREATE OR REPLACE
- TokuDB· 參數故事·數據安全和性能
- TokuDB· HA方案·TokuDB熱備
- 數據庫內核月報 - 2014/08
- MySQL· 參數故事·timed_mutexes
- MySQL· 參數故事·innodb_flush_log_at_trx_commit
- MySQL· 捉蟲動態·Count(Distinct) ERROR
- MySQL· 捉蟲動態·mysqldump BUFFER OVERFLOW
- MySQL· 捉蟲動態·long semaphore waits
- MariaDB·分支特性·支持大于16K的InnoDB Page Size
- MariaDB·分支特性·FusionIO特性支持
- TokuDB· 性能優化·Bulk Fetch
- TokuDB· 數據結構·Fractal-Trees與LSM-Trees對比
- TokuDB·社區八卦·TokuDB團隊