## BUG 1 IN查詢結果不對
### 背景
在mysql5.6.16版本下,構建如下測試用例
~~~
CREATE TABLE `a` (
`c1` varchar(512) NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `a` VALUES ('i-28s18atup'),('i-2850jdoa2'),('i-2872jv9o8'),('i-289z59set'),('i-2812c0mz1'),(''),(''),('i-28xut6ybi'),('i-28w4b8qmq'),('i-289x1nfxb'),('i-28ae3hs3l'),('');
CREATE TABLE `b` (
`c1` varchar(512) NOT NULL DEFAULT ''
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
INSERT INTO `b` VALUES ('i-2872jv9o8'),('i-289z59set'),('i-2812c0mz1'),('i-2816iktqq'),('i-2817bpwuf'),('i-281hwn59l'),('i-281uacgga'),('i-2857ezdnp'),('i-288mhwbtf'),('i-28gpk1d8n'),('i-28imr0oqh'),('i-28k90goqz'),('i-28ljdyl40'),('i-28n95axfc'),('i-28oud8zm4'),('i-28poeqcfg'),('i-28s4qqv37'),('i-28sqirs1x'),('i-28teqx5wl'),('i-28tscpaga'),('i-28udhuliu'),('i-28ukb9exr'),('i-28weof7iq'),('i-28x2ks3t0'),('i-28x4dwhx2'),('i-28xkvidhs'),('i-28yxqwfn3'),('i-280g6jlvv'),('i-281uto1kh'),('i-287sdi05n'),('i-289mdvf5g'),('i-289u2lqsc'),('i-28aay99cm'),('i-28egwihhf'),('i-28f6rjma6'),('i-28gkqmzyr'),('i-28i0fxf1s'),('i-28luhd7ps'),('i-28lv319r0'),('i-28n3qoup1'),('i-28nwfea7f'),('i-28ot1q2xi'),('i-28pyi35g8'),('i-28qu9xsi3'),('i-28rea4oni'),('i-28u67zgrf'),('i-28v3b30me'),('i-28vmsbvfo'),('i-28wjg9vk6'),('i-28y57ow32'),('i-28zvbc1ez'),('i-2808tzqlt'),('i-280lh3rs8'),('i-280qx4wi4'),('i-2822dphhh'),('i-282bi6laz'),('i-286vzupf5'),('i-289j094i1'),('i-28alrnwls'),('i-28cv4vbno'),('i-28f9b4h8i'),('i-28gzw4zy7'),('i-28k22cqsp'),('i-28kks1i6x'),('i-28kzegmw4'),('i-28l7zc3fk'),('i-28mixznev'),('i-28ozch1ez'),('i-28pb5f875'),('i-28ph2u6t6'),('i-28pqnqp7j'),('i-28qcpitrp'),('i-28qqnhqfh'),('i-28u22af72'),('i-28uj4p5tv'),('i-281ivhmz5'),('i-2822cx06o'),('i-282mbjqm0'),('i-283d8bvyb'),('i-283quwmu3'),('i-286g6g1ro'),('i-288j0bnt7'),('i-28by5aph5'),('i-28eieau49'),('i-28f62bsn1'),('i-28hf1eagg'),('i-28i65v11j'),('i-28jxqptk6'),('i-28larsas5'),('i-28opsiq8x'),('i-28phn0vxr'),('i-28qvnojgc'),('i-28suce82g'),('i-28ugoo095'),('i-28vezpnzi'),('i-2807j8ugs'),('i-280by00qq'),('i-280il7op3'),('i-280jkmjaz'),('i-280ntguko'),('i-280oek885'),('i-281bqee7p'),('i-281on7t0b'),('i-281qw9cxp'),('i-281yhxvsv'),('i-281z84d1e'),('i-2822x8yps'),('i-282dkngx2'),('i-282r9e38f'),('i-282rnc33f'),('i-282v6g5h4'),('i-282xiua07'),('i-283182ago'),('i-2832s21gb'),('i-2834tiucp'),('i-283cn5cxq'),('i-283wi9g1h'),('i-283z5b9c0'),('i-2841ipeb4'),('i-28437k5oc'),('i-2846zaxqr'),('i-284984ozz'),('i-284a1ssib'),('i-2855d5g88'),('i-285j5p5bk'),('i-285mc530r'),('i-285x7qkd3'),('i-286ge4k0u'),('i-286jo1dlm'),('i-286l67owf'),('i-286l9nw58'),('i-286sfdy4l'),('i-286wqq5ru'),('i-28782gcz0'),('i-287emfglt'),('i-287gte4x2'),('i-287iojtlb'),('i-287iuvbak'),('i-287krjdsj'),('i-287xw6apz'),('i-288qvr8nc'),('i-288r3rnp5'),('i-288vyt7rn'),('i-28945gqjc'),('i-289o6exr0'),('i-289plb8da'),('i-289zzqybq'),('i-28a7s5emw'),('i-28a80onkx'),('i-28ac0jtrv'),('i-28aljhpg7'),('i-28anbj66d'),('i-28aph3ftl'),('i-28avc59am'),('i-28axepg7l'),('i-28basvzz1'),('i-28bc4rrlf'),('i-28bexmi8s'),('i-28bibye65'),('i-28bt7b3e0'),('i-28c7xkjcx'),('i-28cavwsws'),('i-28d1k1f9a'),('i-28d6vdy8y'),('i-28dbchfjy'),('i-28dnywe05'),('i-28dp7a49v'),('i-28e020whv'),('i-28eeda8sl'),('i-28eei9ril'),('i-28efkucv4'),('i-28eqlvjh7'),('i-28eqoq6jz'),('i-28eu8b3cn'),('i-28ey2azsi'),('i-28ezvmkfw'),('i-28flibcp6'),('i-28fx0xpcy'),('i-28fxgaiky'),('i-28g3txm3b'),('i-28g3v1iry'),('i-28g9b6020'),('i-28gb1btyc'),('i-28gb3ycy0'),('i-28gedglzn'),('i-28gltwwep'),('i-28gq7in88'),('i-28gyuxcbh'),('i-28h3iifgj'),('i-28h62fexn'),('i-28h6aoaad'),('i-28h6t1m4y'),('i-28hmc6k68'),('i-28hwfarg5'),('i-28ia4sfjq'),('i-28iahbwm8'),('i-28ixabmik'),('i-28j9zlf7i'),('i-28jszuxbi'),('i-28jve5u7y'),('i-28jxfhc0t'),('i-28k065l2d'),('i-28k8izbox'),('i-28kkduhlu'),('i-28lds3u8j'),('i-28ll2kzzv'),('i-28lmdk35t'),('i-28lnwhrp9'),('i-28lyjao0s'),('i-28m89ppr9'),('i-28mgx6z78'),('i-28mmrax6a'),('i-28mn693s6'),('i-28mr3daqe'),('i-28msqlshi'),('i-28ne2cj29'),('i-28njhhqlx'),('i-28nrmz2xi'),('i-28obphyxu'),('i-28oqcp376'),('i-28p8gdsa1'),('i-28pkmbhz0'),('i-28pm3ae7s'),('i-28pq0fyad'),('i-28pt7gxr9'),('i-28q3c1uwv'),('i-28qbdjifr'),('i-28qbupqww'),('i-28qeldn3h'),('i-28qh9hm6x'),('i-28qhuqgrb'),('i-28qq7xquk'),('i-28qsp23rw'),('i-28rbr6n7j'),('i-28rd5sit0'),('i-28re1wghi'),('i-28rg46u2o'),('i-28ro15iho'),('i-28rr8t7e9'),('i-28rtwybki'),('i-28s1a15nf'),('i-28s4lcrrk'),('i-28s6gmfdr'),('i-28s75rgku'),('i-28spofoco'),('i-28spzksyq'),('i-28sre8jn1'),('i-28t0bhx0s'),('i-28t5jr47m'),('i-28tf05t7d'),('i-28tqmqj5f'),('i-28tsv0bbf'),('i-28u4wrz31'),('i-28ufrk8ah'),('i-28uoipuyh'),('i-28ur0wkpc'),('i-28uribj7j'),('i-28ut2dbya'),('i-28uv1pvfn'),('i-28v16yjyb'),('i-28v7dt011'),('i-28vj5l7r9'),('i-28vpwpxm8'),('i-28wga3np5'),('i-28wjoby7z'),('i-28wnnsjjt'),('i-28x0ikpj1'),('i-28x70dsak'),('i-28xbvelc6'),('i-28xivp7gj'),('i-28y3qaea3'),('i-28yh1ownr'),('i-28ysliksd'),('i-28zyq34ab'),('i-28xut6ybi'),('i-28w4b8qmq');
select c1 from a where c1='i-28w4b8qmq';
+-------------+
| c1 |
+-------------+
| i-28w4b8qmq |
+-------------+
1 row in set (0.01 sec)
select c1 from b where c1='i-28w4b8qmq';
+-------------+
| c1 |
+-------------+
| i-28w4b8qmq |
+-------------+
set tmp_table_size=16*1024*1024;
explain select c1 from a where c1='i-28w4b8qmq' and c1 in (select c1 from b);
+----+--------------+-------------+--------+---------------+------------+---------+---------------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------+-------------+--------+---------------+------------+---------+---------------+------+-------------+
| 1 | SIMPLE | a | ALL | NULL | NULL | NULL | NULL | 12 | Using where |
| 1 | SIMPLE | <subquery2> | eq_ref | <auto_key> | <auto_key> | 1538 | cleaneye.a.c1 | 1 | NULL |
| 2 | MATERIALIZED | b | ALL | NULL | NULL | NULL | NULL | 276 | NULL |
+----+--------------+-------------+--------+---------------+------------+---------+---------------+------+-------------+
select c1 from a where c1='i-28w4b8qmq' and c1 in (select c1 from b);
c1
+-------------+
| c1 |
+-------------+
| i-28w4b8qmq |
+-------------+
set tmp_table_size=262144;
explain select c1 from a where c1='i-28w4b8qmq' and c1 in (select c1 from b);
+----+--------------+-------------+--------+---------------+------------+---------+---------------+------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+--------------+-------------+--------+---------------+------------+---------+---------------+------+-------------+
| 1 | SIMPLE | a | ALL | NULL | NULL | NULL | NULL | 12 | Using where |
| 1 | SIMPLE | <subquery2> | eq_ref | <auto_key> | <auto_key> | 1538 | cleaneye.a.c1 | 1 | NULL |
| 2 | MATERIALIZED | b | ALL | NULL | NULL | NULL | NULL | 276 | NULL |
+----+--------------+-------------+--------+---------------+------------+---------+---------------+------+-------------+
select c1 from a where c1='i-28w4b8qmq' and c1 in (select c1 from b); // 查詢結果為空,預期結果應返回一行
Empty set (0.01 sec)
~~~
從例子可以看到當tmp_table_size=262144時,查詢結果不對,而tmp_table_size=1610241024時查詢結果是正確的。
### 分析
查詢結果跟tmp_table_size有關,而tmp_table_size是控制查詢時生成的臨時表是MEMORY還是MyISAM類型的。臨時表超過tmp_table_size會生成MyISAM類型的。
另外,查詢計劃中可以看到MATERIALIZED,MATERIALIZED優化是將子查詢的結果存儲在臨時表中,避免多次執行子查詢。
而5.6存在一個問題是,MATERIALIZED對MyISAM臨時表中存在unique constraint的情況支持不友好。此問題直到5.7才解決,參見[worklog#6711](https://dev.mysql.com/worklog/task/?id=6711)
> MyISAM表中unique constraint,是指當MyISAM中存在blob,或key長度超長時, 索引會自動轉為unique constraint
> unique constraint會自動增加一列存記錄的hash值, 以下是代碼片段
~~~
create_myisam_tmp_table:
if (keyinfo->key_length >= table->file->max_key_length() ||
keyinfo->user_defined_key_parts > table->file->max_key_parts() ||
share->uniques)
{
/* Can't create a key; Make a unique constraint instead of a key */
share->keys= 0;
share->uniques= 1;
using_unique_constraint=1;
memset(&uniquedef, 0, sizeof(uniquedef));
uniquedef.keysegs=keyinfo->user_defined_key_parts;
uniquedef.seg=seg;
uniquedef.null_are_equal=1;
/* Create extra column for hash value */
memset(*recinfo, 0, sizeof(**recinfo));
(*recinfo)->type= FIELD_CHECK;
(*recinfo)->length=MI_UNIQUE_HASH_LENGTH;
(*recinfo)++;
share->reclength+=MI_UNIQUE_HASH_LENGTH;
~~~
而本例中,c1字段varchar(512)是utf8字符集 512*3 > 1000 超過最大key大小,正好進入上述代碼邏輯。
子查詢先物化到此臨時表,然后后續查詢從臨時表讀數據,然而這里對unique constraint的讀取操作(ha_myisam::index_read_map)還不支持
~~~
ha_myisam::index_read_map
handler::ha_index_read_map
join_read_key
sub_select
evaluate_join_record
sub_select
do_select
JOIN::exec
mysql_execute_select
mysql_select
handle_select
~~~
讀取出錯后得到HA_ERR_KEY_NOT_FOUND,此錯誤并沒有退出。從而導致外界認為查詢結果為空集,所以我們測例中的查詢也錯誤的返回了空集。
~~~
error= table->file->ha_index_read_map(table->record[0],
tab->ref.key_buff,
make_prev_keypart_map(tab->ref.key_parts), HA_READ_KEY_EXACT);
if (error &&
error != HA_ERR_KEY_NOT_FOUND && error != HA_ERR_END_OF_FILE)
error= report_handler_error(table, error);
else{
~~~
### 修復
雖然5.7修復了此問題,但改動較大,同時還存在部分bug.
5.6采取了折衷的修復方法,當MyISAM臨時表存在unique contraint時,則不采用MATERIALIZED優化,從而避免了產生MyISAM臨時表。
修復方法參見[bugfix](https://github.com/mysql/mysql-server/commit/a24950aca8530fe04782e24de1d40a91e1ec023f)
## BUG 2 表不存在
### 現象
從備份集中恢復的實例中查詢發現表不存在,但實際frm,idb文件都存在
~~~
select * from t2;
Table 'test.t2' doesn't exist
~~~
從備份的源實例中查看,貌似一切正常
~~~
show create table t2;
CREATE TABLE `t2` (
`c1` int(11) NOT NULL,
`c2` int(11) DEFAULT NULL,
PRIMARY KEY (`c1`),
CONSTRAINT `t2_ibfk_1` FOREIGN KEY (`c2`) REFERENCES `t1` (`c1`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
show create table t1;
Create Table
t1 CREATE TABLE `t1` (
`c1` int(11) NOT NULL,
`c2` int(11) DEFAULT NULL,
PRIMARY KEY (`c1`)
) ENGINE=InnoDB DEFAULT CHARSET=latin1
~~~
### 分析
首先,懷疑是備份集的問題。因此,重新備份后再測試,依然是表不存在。
排除備份集的問題后,通過調試源碼的方法來找原因
~~~
dict_foreign_qualify_index
dict_foreign_find_index
dict_foreign_add_to_cache
dict_load_foreign
dict_load_foreigns
dict_load_table
dict_table_open_on_name
ha_innobase::open
handler::ha_open
open_table_from_share
open_table
open_and_process_table
open_tables
open_normal_and_derived_tables
execute_sqlcom_select
mysql_execute_command
~~~
上述堆棧是表在load過程中構建foreign信息。查找t2表列c2的foreign key時失敗了。
查看INNODB_SYS_INDEXES表也可以發現,t2上只有一個primary索引,外鍵約束雖在,但外鍵在t2上的索引并不存在。
~~~
select * from information_schema.INNODB_SYS_TABLES t,information_schema.INNODB_SYS_indexes i,information_schema.INNODB_SYS_fields f where t.name='test/t2' and t.table_id=i.table_id and i.index_id=f.index_id;
+----------+---------+------+--------+-------+-------------+------------+---------------+----------+---------+----------+------+----------+---------+-------+----------+------+-----+
| TABLE_ID | NAME | FLAG | N_COLS | SPACE | FILE_FORMAT | ROW_FORMAT | ZIP_PAGE_SIZE | INDEX_ID | NAME | TABLE_ID | TYPE | N_FIELDS | PAGE_NO | SPACE | INDEX_ID | NAME | POS |
+----------+---------+------+--------+-------+-------------+------------+---------------+----------+---------+----------+------+----------+---------+-------+----------+------+-----+
| 21 | test/t2 | 1 | 5 | 7 | Antelope | Compact | 0 | 23 | PRIMARY | 21 | 3 | 1 | 3 | 7 | 23 | c1 | 0 |
+----------+---------+------+--------+-------+-------------+------------+---------------+----------+---------+----------+------+----------+---------+-------+----------+------+-----+
select * from information_schema.INNODB_SYS_FOREIGN f,information_schema.INNODB_SYS_FOREIGN_COLS fc where f.for_name='test/t2' and f.id=fc.id;
+----------------+----------+----------+--------+------+----------------+--------------+--------------+-----+
| ID | FOR_NAME | REF_NAME | N_COLS | TYPE | ID | FOR_COL_NAME | REF_COL_NAME | POS |
+----------------+----------+----------+--------+------+----------------+--------------+--------------+-----+
| test/t2_ibfk_1 | test/t2 | test/t1 | 1 | 0 | test/t2_ibfk_1 | c2 | c1 | 0 |
+----------------+----------+----------+--------+------+----------------+--------------+--------------+-----+
~~~
### 場景恢復
為什么外鍵在t2上的索引會不存在呢,是參數FOREIGN_KEY_CHECKS搗的鬼,我們看看如下例子
~~~
create table t1(c1 int primary key, c2 int) engine=innodb;
create table t2(c1 int primary key, c2 int , key idx1(c2), foreign key (c2) references t1(c1)) engine=innodb;
set FOREIGN_KEY_CHECKS=1;
alter table t2 drop key idx1;
ERROR 1553 (HY000): Cannot drop index 'c2': needed in a foreign key constraint
set FOREIGN_KEY_CHECKS=0;
alter table t2 drop key idx1;//可以刪除成功
~~~
刪除后表還是可以正常訪問的。但一旦表定義踢出緩存或數據庫重啟,重新加載數據字典信息時,就會出現前面堆棧中的找不到外鍵索引的問題,從而導致表不存在的錯誤。
這個錯誤是非常嚴重的,會導致用戶無法訪問數據。
一旦出現此種情況,需要修改代碼繞過加載外鍵數據字典信息的錯誤,才能恢復出數據,比較麻煩。
而對于我們源實例的場景算比較幸運,t2的表定義還在內存中,這時只需要把idx1重新建回去即可。再重新備份就可以生成有效的備份集了。
### 修復
此bug出現在版本5.5,5.6中,5.7已修復參考[bug#76940](http://bugs.mysql.com/bug.php?id=76940)
修復方法是FOREIGN_KEY_CHECKS=0時不允許刪除外鍵所在索引。
- 數據庫內核月報目錄
- 數據庫內核月報 - 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團隊