在使用PostgreSQL數據庫過程中,對SQL調優最常用的手段是使用explain查看執行計劃,很多時候我們只關注了執行計劃的結果而未深入了解執行計劃是如何生成的。優化器作為數據庫核心功能之一,也是數據庫的“大腦”,理解優化器將有助于我們更好地優化SQL,下面將會為大家解開PostgreSQL優化器神秘的面紗。
## SQL執行過程

在PG數據庫中,對于DDL語句無需進行優化,到utility模塊處理,對于DML語句需要到優化器中處理,一個用戶連接從接收SQL到執行的流程如下:

## 查詢重寫
主要目的是為了消除view、rule等,如下示例,視圖v_t_1_2在執行計劃里面已經被t1、t2替換。
~~~
create view v_t_1_2 as SELECT t1.a1, t1.b1, t2.a2, t2.b2 FROM t1, t2;
postgres=> explain select * from v_t_1_2, t1 where v_t_1_2.a1 = 10 and t1.b1 = 20; QUERY PLAN
-------------------------------------------------------------------------------------
Nested Loop (cost=0.55..41.59 rows=1000 width=24)
-> Nested Loop (cost=0.55..16.60 rows=1 width=16)
-> Index Scan using t1_a1_key on t1 t1_1 (cost=0.28..8.29 rows=1 width=8)
Index Cond: (a1 = 10)
-> Index Scan using b1_1 on t1 (cost=0.28..8.29 rows=1 width=8)
Index Cond: (b1 = 20)
-> Seq Scan on t2 (cost=0.00..15.00 rows=1000 width=8)
(7 rows)
~~~
## 提升子鏈
目標是將IN和exists子句遞歸提升。
select * from t1 where t1.a1 in (select t2.a2 from t2 where t2.b2 = 10); 假設t2.a2為unique
轉化為:
select t1.a1,t1,a2 from t1 join t2 where t1.a1=t2.a2 and t2.b2 = 10;
in子鏈接執行計劃如下:
~~~
postgres=> explain select * from t1 where t1.a1 in (select t2.a2 from t2 where t2.b2 = 10);
QUERY PLAN
--------------------------------------------------------------------------
Nested Loop (cost=0.28..25.80 rows=1 width=8)
-> Seq Scan on t2 (cost=0.00..17.50 rows=1 width=4)
Filter: (b2 = 10)
-> Index Scan using t1_a1_key on t1 (cost=0.28..8.29 rows=1 width=8)
Index Cond: (a1 = t2.a2)
~~~
explain select * from t1 where exists (select t2.a2 from t2 where t2.a2 = t1.a1) ; 假設t2.a2為unique
轉化為:
select t1.a1, t1.b1 from t1, t2 where t1.a1=t2.a1;
exists子鏈接執行計劃如下:
~~~
postgres=> explain select * from t1 where exists (select t2.a2 from t2 where t2.a2 = t1.a1) ;
QUERY PLAN
-----------------------------------------------------------------
Hash Join (cost=26.42..54.69 rows=952 width=8)
Hash Cond: (t2.a2 = t1.a1)
-> Seq Scan on t2 (cost=0.00..15.00 rows=1000 width=4)
-> Hash (cost=14.52..14.52 rows=952 width=8)
-> Seq Scan on t1 (cost=0.00..14.52 rows=952 width=8)
(5 rows)
~~~
## 提升子查詢
子查詢和子鏈接區別:子查詢不在表達式中子句,子鏈接在in/exists表達式中的子句。
select * from t1, (select * from t2) as c where t1.a1 = c.a2;
轉化為:
select * from t1, t2 where t1.a1 = t2.a2;
~~~
postgres=> explain select * from t1, (select * from t2) as c where t1.a1 = c.a2;
QUERY PLAN
-----------------------------------------------------------------
Hash Join (cost=26.42..54.69 rows=952 width=16)
Hash Cond: (t2.a2 = t1.a1)
-> Seq Scan on t2 (cost=0.00..15.00 rows=1000 width=8)
-> Hash (cost=14.52..14.52 rows=952 width=8)
-> Seq Scan on t1 (cost=0.00..14.52 rows=952 width=8)
(5 rows)
~~~
并不是所有的子查詢都能提升,含有集合操作、聚合操作、sort/limit/with/group、易失函數、from為空等是不支持提升的。
如下:
~~~
postgres=> explain select t1.a1 from t1, (select a2 from t2 limit 1) as c where c.a2 = 10;
QUERY PLAN
------------------------------------------------------------------------
Nested Loop (cost=0.00..24.07 rows=952 width=4)
-> Subquery Scan on c (cost=0.00..0.03 rows=1 width=0)
Filter: (c.a2 = 10)
-> Limit (cost=0.00..0.01 rows=1 width=4)
-> Seq Scan on t2 (cost=0.00..15.00 rows=1000 width=4)
-> Seq Scan on t1 (cost=0.00..14.52 rows=952 width=4)
(6 rows)
~~~
## 化簡條件
包含邏輯推理、表達式計算等

## 外連接消除(left/right/full join)
以left join為例,left join(左連接) 返回包括左表中的所有記錄和右表中連接字段相等的記錄 ,如果右表沒有匹配的記錄,那么右表將會以NULL值代替,例如:
~~~
A表 B表
ID1 ID2
1 1
2
select * from A left join B on A.id1 = B.id2;
結果如下:
ID1 ID2
1 1
2 NULL
~~~
存在外連接left join
~~~
postgres=> explain select * from t1 left join t2 on true;
QUERY PLAN
-------------------------------------------------------------------
Nested Loop Left Join (cost=0.00..11932.02 rows=952000 width=16)
-> Seq Scan on t1 (cost=0.00..14.52 rows=952 width=8)
-> Materialize (cost=0.00..20.00 rows=1000 width=8)
-> Seq Scan on t2 (cost=0.00..15.00 rows=1000 width=8)
(4 rows)
~~~
消除外連接需要where和join條件保證右表不會有NULL值的行產生。
~~~
postgres=> explain select * from t1 left join t2 on t1.b1 = t2.b2 where t2.b2 is not NULL;
QUERY PLAN
---------------------------------------------------------------------
Nested Loop (cost=0.28..23.30 rows=1 width=16)
-> Seq Scan on t2 (cost=0.00..15.00 rows=1 width=8)
Filter: (b2 IS NOT NULL)
-> Index Scan using b1_1 on t1 (cost=0.28..8.29 rows=1 width=8)
Index Cond: (b1 = t2.b2)
(5 rows)
~~~
## 條件下推
條件下推的目的為了連接前,元組數組盡量少,如下示例,條件已經下推到每個表上面了。
~~~
postgres=> explain select * from t1,t2 where t1.a1 < 10 and t2.a2 > 900;
QUERY PLAN
---------------------------------------------------------------------------------
Nested Loop (cost=0.55..31.20 rows=1000 width=16)
-> Index Scan using t2_a2_key on t2 (cost=0.28..10.03 rows=100 width=8)
Index Cond: (a2 > 900)
-> Materialize (cost=0.28..8.70 rows=10 width=8)
-> Index Scan using t1_a1_key on t1 (cost=0.28..8.65 rows=10 width=8)
Index Cond: (a1 < 10)
~~~
## 語義優化
當表中字段存在約束鍵時,PostgreSQL將會對其進行語義優化,因為查詢條件有可能已經隱含滿足或者不滿足,例如:
~~~
create table tt1(id int not null);
postgres=> explain select * from tt1 where id is null;
QUERY PLAN
--------------------------------------------------------
Seq Scan on tt1 (cost=0.00..15407.02 rows=1 width=15)
Filter: (id IS NULL)
set constraint_exclusion = on;
postgres=> explain select * from tt1 where id is null;
QUERY PLAN
------------------------------------------
Result (cost=0.00..0.01 rows=1 width=0)
One-Time Filter: false
~~~
表tt1的id字段已經隱含了不為NULL,所以id=null這種條件可以直接返回false,PostgreSQL數據庫默認并沒有開啟約束優化,需要設置constraint_exclusion這個參數。
## MIN/MAX優化
min/max函數在應用的使用中是非常廣泛的,數據庫有必要對其進行特殊優化,比如索引中已經將數據排好序了,最大最小值可以直接獲取到,所以PostgreSQL對min/max函數做了一步轉化。
select min(a1) from t1 轉化為 select a1 from t1 order by a1 limit 1;
如果a1沒有索引,那么將會是順序掃描,不進行轉化。
~~~
postgres=> explain select min(a1) from t1;
QUERY PLAN
------------------------------------------------------------------------------------------
Result (cost=0.32..0.33 rows=1 width=0)
InitPlan 1 (returns $0)
-> Limit (cost=0.28..0.32 rows=1 width=4)
-> Index Only Scan using t1_a1_key on t1 (cost=0.28..45.09 rows=952 width=4)
Index Cond: (a1 IS NOT NULL)
~~~
## group by優化
如果不對group by優化,那么將會需要對結果進行Sort或者Hash,但是如果表中數據已經是排序好的,那么將可以對其進行優化。
~~~
create index tt1_id_key on tt1 using btree ( id);
postgres=> explain select id from tt1 group by id;
QUERY PLAN
-------------------------------------------------------------------------------------------
Group (cost=0.42..33891.21 rows=1000102 width=4)
Group Key: id
-> Index Only Scan using tt1_id_key on tt1 (cost=0.42..31390.96 rows=1000102 width=4)
postgres=> explain select name from tt1 group by name;
QUERY PLAN
--------------------------------------------------------------------------
Group (cost=132169.76..137170.27 rows=1000102 width=11)
Group Key: name
-> Sort (cost=132169.76..134670.02 rows=1000102 width=11)
Sort Key: name
-> Seq Scan on tt1 (cost=0.00..15407.02 rows=1000102 width=11)
~~~
## order by優化
1\. 利用索引消除order by
~~~
postgres=> explain select * from t1 order by a1;
QUERY PLAN
-----------------------------------------------------------------------
Index Scan using t1_a1_key on t1 (cost=0.28..42.71 rows=952 width=8)
(1 row)
~~~
2\. order by下推,利用merge join實現更快的連接
~~~
postgres=> explain select * from t1,t2 where t1.b1=t2.b2 order by b1;
QUERY PLAN
------------------------------------------------------------------
Merge Join (cost=126.45..136.22 rows=1 width=16)
Merge Cond: (t1.b1 = t2.b2)
-> Sort (cost=61.62..64.00 rows=952 width=8)
Sort Key: t1.b1
-> Seq Scan on t1 (cost=0.00..14.52 rows=952 width=8)
-> Sort (cost=64.83..67.33 rows=1000 width=8)
Sort Key: t2.b2
-> Seq Scan on t2 (cost=0.00..15.00 rows=1000 width=8)
(8 rows)
~~~
## distinct優化
類似于group by優化,distinct將會從Sort和Hash中選擇最優的,如果字段中有索引,Sort代價可能會更低。
~~~
postgres=> explain select distinct(a1) from t1;
QUERY PLAN
-----------------------------------------------------------
HashAggregate (cost=16.90..26.42 rows=952 width=4)
Group Key: a1
-> Seq Scan on t1 (cost=0.00..14.52 rows=952 width=4)
(3 rows)
postgres=> explain select distinct(name) from tt1;
QUERY PLAN
--------------------------------------------------------------------------
Unique (cost=132169.76..137170.27 rows=1000102 width=11)
-> Sort (cost=132169.76..134670.02 rows=1000102 width=11)
Sort Key: name
-> Seq Scan on tt1 (cost=0.00..15407.02 rows=1000102 width=11)
~~~
## 集合操作優化
集合操作union被轉換成Append方式。
~~~
postgres=> explain select a1 from t1 where a1 < 10 union select a2 from t2;
QUERY PLAN
--------------------------------------------------------------------------------------
HashAggregate (cost=36.28..46.38 rows=1010 width=4)
Group Key: t1.a1
-> Append (cost=0.28..33.75 rows=1010 width=4)
-> Index Only Scan using t1_a1_key on t1 (cost=0.28..8.65 rows=10 width=4)
Index Cond: (a1 < 10)
-> Seq Scan on t2 (cost=0.00..15.00 rows=1000 width=4)
postgres=> explain select a1 from t1 where a1 < 10 union all select a2 from t2;
QUERY PLAN
--------------------------------------------------------------------------------
Append (cost=0.28..23.75 rows=1010 width=4)
-> Index Only Scan using t1_a1_key on t1 (cost=0.28..8.65 rows=10 width=4)
Index Cond: (a1 < 10)
-> Seq Scan on t2 (cost=0.00..15.00 rows=1000 width=4)
~~~
## 總結
以上介紹了幾種常見的PostgreSQL優化器對SQL優化的方法,這些方法更著重于SQL邏輯優化,也就是盡量對SQL進行等價或者推倒變換,以達到更有效率的執行計劃。PostgreSQL優化器原理遠不止這些,比如表的掃描方式選擇、多表組合方式、多表組合順序等,這些內容將會在后續的月報中繼續呈現。
- 數據庫內核月報目錄
- 數據庫內核月報 - 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團隊