資料庫關聯查詢表順序的影響,大表和小表的前後順序有關係?

時間 2022-01-05 18:00:35

1樓:董長佐

這個問題回答起來比較麻煩,case 比較多。

case 1: 兩張表都沒有索引

因為沒有索引,所以nature join會對兩個表做全表掃瞄。大致過程是從前表中load 乙個輸入緩衝區大小的資料塊進記憶體,然後從後表中load 乙個輸入緩衝區大小的資料進記憶體,然後兩個輸入緩衝區中的資料做nature join,join結果寫進輸出緩衝區。然後後表的輸入緩衝區清空,再從後表中load 第二塊輸入緩衝區大小的資料,繼續和前表輸入緩衝區中的資料做nature join,將結果寫進輸出緩衝區。

以此類推,當後表遍歷完一遍之後,前表load第二塊輸入緩衝區大小的資料,後表再依次load 第一塊,第二塊,到第n塊。

那cost 是多少呢?比如前表有a塊緩衝區大小的資料,後表有b塊緩衝區大小的資料,那cost 就是 a*b*(transfer time)+ 2a * (seek time)+ a*(transfer time),其中 transfer time 表示一塊緩衝區大小的資料從硬碟load 到記憶體的時間,seek time表示磁碟塊的定址時間

所以,前表較小的時候(即a較小的時候),總體時間會小。

結論:小表在前好

case 2: 小表無索引,大表有索引,而且基於索引列做nature join

這種情況,必須小表在前,但小表在前,有多大的效能提公升,要看大表的索引型別。

大表聚集索引,效能提公升較大

大表非聚集索引,效能有可能同全表掃瞄差不多。

結論:小表在前好

case 3: 小表有索引,大表無索引,而且是基於索引列做nature join

這種情況需要關注大表在前,使用小表索引,會不會帶來效能提公升。

小表非聚集索引,效能有可能同全表掃瞄差不多,那效能就趕不上小表在前了

小表聚集索引,效能可能提公升較大

結論:大小表誰在前不一定,需要看小表的索引情況和大小表的相對資料量大小

2樓:宋澐劍

現在關聯式資料庫如何寫沒有關係,資料庫優化引擎會在解析階段根據索引和統計資訊選擇合理的執行計畫。對於乙個大表和乙個小表做連線來說,小表是外表做掃瞄,對於其中每一行到內錶也就是大表中做查詢。

3樓:Feng Guangpu

小表優先能極大減少比對次數效率更好

例子:a表1條記錄

b表10000條記錄

連線條件是a.id = b.id

假設都有索引

先從a表找就只需要確定b表中有無滿足條件的記錄,1次就ok如果先從b表找,就需要找10000次

小白求教如何設計資料庫的表?

先把所有的類列出來,在把需要儲存在資料庫的類找到,把主外來鍵關係找到,你就可以建立表了,至於你如何約束字段,那就是你的事了,每張表的字段盡量不重複,至於索引,那就是你最常訪問的字段做最好。 符合BCNF正規化即可 一般人常規思考都能符合這個正規化 能記錄越多資訊越好 免得以後要實現新功能,結果資訊不...

建立資料庫表有哪些好用的工具 類似Power Designer?

leohxj 說幾個 web 工具。Database Relationship Diagrams Design Tool 通過自定義的 SDL dbml 描述表結構。寫起來比較直觀,有點 ORM 定義的感覺,並且 VSC 也有外掛程式,可以高亮和輔助編寫。然後將內容貼到上面的視覺化工具中用於展示。這...

資料庫,多對多的關係一定要使用中間表嗎?

Li Chun 題主提出的這種方法 如果我用乙個欄位來記錄行不行 比如話題用問題之間 我在乙個話題的乙個欄位中記錄它下面所有問題的ID,問題一也用乙個字段記錄它屬性話題的ID 可能在一些非關係型的資料庫中更為常見,比如一些key value或者是文件型的 比如mongodb 資料庫,使用這樣的方法,...