我想到這個(gè)問題是從觀察mysql的自然排序狀態(tài)引發(fā)的，我們用的很多mysql管理軟件，在列出表數(shù)據(jù)時(shí)一般都用的以下代碼SELECT * FROM table_name LIMIT x OFFSET y這個(gè)時(shí)候沒有指定任何排序字段，那么在mysql內(nèi)部就應(yīng)該有一個(gè)類似oracle或者pgsql里面sequence id的東西，做為它的默認(rèn)索引來實(shí)現(xiàn)排序之類的東西。但我從來沒看到有人提過mysql有這個(gè)玩意。另一個(gè)佐證是如果你指定了一個(gè)自增id作為主鍵，在我們預(yù)想中如果執(zhí)行上面的語句，主鍵的排序順序應(yīng)該一致，實(shí)際上并不是這樣，雖然大部分是一致的，但是有少部分會(huì)打亂。
2 回答
牛魔王的故事
TA貢獻(xiàn)1830條經(jīng)驗(yàn) 獲得超3個(gè)贊
單說MyISAM吧。 MyISAM的數(shù)據(jù)和索引是分開的，當(dāng)你執(zhí)行一個(gè)簡單的select *的時(shí)候，按照的就是數(shù)據(jù)在磁盤上的排列順序（你可以把這個(gè)順序理解為sequenceid）。 但是必須指出的是，數(shù)據(jù)空間是會(huì)復(fù)用的，也就是說當(dāng)你在插入一行數(shù)據(jù)的時(shí)候，如果前面被刪除的區(qū)塊有合適空位，就會(huì)放到這空位中。 因此select *并不保證是按照插入順序。 不知道這么說有木有清楚。
開滿天機(jī)
TA貢獻(xiàn)1786條經(jīng)驗(yàn) 獲得超13個(gè)贊
select * from tb limit oo offset xx; 這種查詢是不走索引的，也就是說根本就不排序，結(jié)果的順序是你寫入數(shù)據(jù)的順序。
mysql索引是這樣的。myisam各種沒底線，沒限制，每一個(gè)索引葉子節(jié)點(diǎn)存索引列值，指向數(shù)據(jù)在磁盤的地址。innodb，要求每張表有一個(gè)聚簇索引，這東西默認(rèn)是Primary Key，沒有的話就是第一個(gè)unique key，再?zèng)]有就自己創(chuàng)建一個(gè)autoincrement。這個(gè)聚簇索引排成一棵B樹，每個(gè)葉子是局促的那個(gè)字段值，指向整行數(shù)據(jù)。其他的索引都叫二級索引，存的是索引列值，指向聚簇索引的列值。這些索引單獨(dú)存儲(chǔ)，所以不知名道姓的說用他們，他們是不會(huì)出來的，尤其是select * 這種操作，反正是要去取出所有的數(shù)據(jù)的，而且沒要求排序，那么再走一次PK排序，會(huì)慢，所以就直接順序讀出來了。
---- 補(bǔ)充 ----
MyISAM的存儲(chǔ)順序就是寫入順序，他是順著一個(gè)一個(gè)的寫下去的，所以MyISAM查出來的，完全按照寫入順序。innodb的存儲(chǔ)分頁的，每一個(gè)page里的數(shù)據(jù)是按照聚簇索引排序的，但是page之間是無序的，所以會(huì)發(fā)現(xiàn)，在數(shù)據(jù)量比較小的時(shí)候，會(huì)發(fā)現(xiàn)查出來的數(shù)據(jù)其實(shí)還是按照聚簇索引的asc排序的，但是數(shù)據(jù)多了就會(huì)出現(xiàn)部分?jǐn)?shù)據(jù)混亂，就是因?yàn)閜age之間的順序是亂的。
添加回答
舉報(bào)
0/150
提交
取消