Mysql join聯(lián)表及id自增實(shí)例解析

join的寫法

如果用left join 左邊的表一定是驅(qū)動表嗎？兩個表的join包含多個條件的等值匹配，都要寫道on還是只把一個寫到on，其余寫道where部分？

create	table	a(f1	int,	f2	int,	index(f1))engine=innodb;
 create	table	b(f1	int,	f2	int)engine=innodb;
 insert	into	a	values(1,1),(2,2),(3,3),(4,4),(5,5),(6,6);
 insert	into	b	values(3,3),(4,4),(5,5),(6,6),(7,7),(8,8);
select	*	from	a	left	join	b	on(a.f1=b.f1)	and	(a.f2=b.f2);	/*Q1*/
 select	*	from	a	left	join	b	on(a.f1=b.f1)	where	(a.f2=b.f2);/*Q2*/

執(zhí)行結(jié)果：

由于表b沒有索引，使用的是Block Nexted Loop Join(BNL)算法

• 把表a的內(nèi)容讀入join_buffer中，因?yàn)閟elect * ，所以字段f1，f2都被放入
• 順序掃描b，對于每一行數(shù)據(jù)，判斷join條件是否滿足，滿足條件的記錄，作為結(jié)果集的一行，如果有where子句，判斷where部分滿足條件后再返回。
• 表b掃描完成后，對于沒有匹配的表a的行，用null補(bǔ)上，放到結(jié)果集中。

Q2語句中，explain結(jié)果：

b為驅(qū)動表，如果一條語句EXTRA字段什么都沒有的話，就是Index Nested_Loop Join算法，因此流程是：

順序掃描b，每一行用b.f1到a中去查，匹配a.f2=b.f2是否滿足，作為結(jié)果集返回。

Q1與Q2執(zhí)行流程的差異是因?yàn)閮?yōu)化器基于Q2這個查詢語義做了優(yōu)化：在mysql里，null跟任何值執(zhí)行等值判斷和不等值判斷的結(jié)果都是null，包括select null = null 也返回null。

在Q2中，where a.f2 = b.f2表示，查詢結(jié)果里不會包含b.f2是null的行，這樣left join語義就是找到兩個表里f1 f2對應(yīng)相同的行，如果a存在而b匹配不到，就放棄。因此優(yōu)化器把這條語句的left join改寫成了join，因?yàn)閍的f1有索引，就把b作為驅(qū)動表，這樣可以用NLJ算法，所以在使用left join時，左邊的表不一定是驅(qū)動表。

如果需要left join的語義，就不能把被驅(qū)動表的字段放在where條件里做等值判斷或不等值判斷，必須寫在on里面。

Nested Loop Join的性能問題

BLN算法的執(zhí)行邏輯

• 將驅(qū)動表的數(shù)據(jù)全部讀入join_buffer中，里面是無序數(shù)組。
• 順序遍歷被驅(qū)動表的所有行，每一行都跟join_buffer做匹配，成功則作為結(jié)果集的一部分返回。

Simple Nested Loop Join算法邏輯是：順序去除驅(qū)動表的每一行數(shù)據(jù)，到被驅(qū)動表做全表匹配。

兩者差異：

在對被驅(qū)動表做全表掃描時，如果數(shù)據(jù)沒有在buffer pool中，需要等待部分?jǐn)?shù)據(jù)從磁盤讀入。會影響正常業(yè)務(wù)的buffer pool命中率，而且會對被驅(qū)動表做多次訪問，更容易將這些數(shù)據(jù)頁放到buffer pool頭部。所以BNL算法性能會更好。自增id

mysql中自增id定義了初始值，不停的增長，但是有上限，2^32-1，自增的id用完了會怎么樣呢。

表定義的自增值達(dá)到上限后，再申請下一個id時，得到的值保持不變。再次插入時會報(bào)主鍵沖突錯誤。所以在建表時，如果有頻繁的增刪改時，就應(yīng)該創(chuàng)建8個字節(jié)的bigint unsigned。

innodb 系統(tǒng)自增row_id

如果創(chuàng)建了Innodb表沒有指定主鍵，那么innodb會創(chuàng)建一個不可見的，長度為6個字節(jié)的row_id，所有無主鍵的innodb表，每插入一行數(shù)據(jù)，都將當(dāng)前的dict_sys.row_id值作為要插入數(shù)據(jù)的row_id，然后自增1。

實(shí)際上，代碼實(shí)現(xiàn)時，row_id是一個長度為8字節(jié)的無符號長整形，但是innodb在設(shè)計(jì)時，給row_id只是6個字節(jié)的長度，這樣寫道數(shù)據(jù)時只放了最后6個字節(jié)。所以：

• row_id寫入表的范圍是0到2^48-1;
• 當(dāng)達(dá)到最大時，如果再有插入數(shù)據(jù)的行為來申請row_id，拿到以后再去最后6個字節(jié)就是0，然后繼續(xù)循環(huán)。
• 再innodb的邏輯里，達(dá)到最大后循環(huán)，新數(shù)據(jù)會覆蓋已經(jīng)存在的數(shù)據(jù)。

從這個角度看，我們應(yīng)該主動創(chuàng)建自增主鍵，這樣達(dá)到上限后，插入數(shù)據(jù)會報(bào)錯。數(shù)據(jù)的可靠性會更加有保障。

XID

redo log 和 binlog相互配合的時候，它們有一個共同的字段就是xid，在mysql中對應(yīng)事務(wù)的。xid最大時2^64次方，用盡只存在理論。

thread_id

系統(tǒng)保存了全局變量thread_id_counter，每新建一個連接，就將thread_id_counter賦值給這個新連接的線程變量。thread_id_counter定義的大小是4個字節(jié)，因此到2^32-1就會重置為0，然后繼續(xù)增加。但是show processlist里不會看到兩個相同的thread_id，這是因?yàn)閙ysql設(shè)計(jì)了一個唯一數(shù)組邏輯，給新線程分配thread_id的時候：

do	{
 		new_id=	thread_id_counter++;
 }	while	(!thread_ids.insert_unique(new_id).second);

以上就是本文的全部內(nèi)容，希望對大家的學(xué)習(xí)有所幫助，也希望大家多多支持腳本之家。