不同的行而不是行

-5

一號方案：一個表用戶列：CUST_ID，名字，姓氏（有10萬行）

第二方案：通過CUST_ID命名 100 000表（每個表只有一排）

我不問它應該如何 - 我知道第二個例子不是很聰明 - 但我想知道哪一個查詢更快？是，如果更快的查詢

select name from users where cust_id = 194923 
-> one result: John Doe

或

select name from users_194923 
-> one result: John Doe

來源

2013-03-15 emte

當你嘗試時發生了什麼？ – 2013-03-15 12:19:16

這個問題可能更適合http://dba.stackexchange.com（這裏可能有重複？） – 2013-03-15 12:19:25

第二個不是「*不是很聰明*」，它是完全沒用的。即使速度更快，您也會在很多其他地方失去表現。甚至不要考慮這個解決方案。 – 2013-03-15 12:19:50

只是一個快速的鍛鍊：

你覺得當服務器處理select * from table_123456發生什麼呢？有各種各樣的魔法發生，但服務器仍然需要確定表table_123456是否存在。在大多數數據庫服務器中，驗證存在名爲table_123456的表的大致時間與驗證id=123456行是否存在索引表中的時間大致相同。例如，SQL Server將表名稱保存在名爲sys.tables的系統表中。

想象一下，編寫一個查詢將返回所有名爲「Peter」的用戶將會有多麼有趣。比較這兩種方法是wronger than wrong。

來源

2013-03-15 13:27:43 SWeko

100 000 tables真的嗎？不要這樣做！

顯然第二個更快，因爲你知道它是什麼表，只有一個記錄。但是這裏有一個問題，如果你想搜索5個人呢？你是怎樣做的？如果你不知道那個人存放在哪裏呢？

數據庫服務器旨在存儲巨大的記錄集（不是每個表一個記錄）。

如果您關心搜索記錄，只需在您想要通常搜索的列上定義一個索引即可。

來源

2013-03-15 12:21:33

我想知道爲什麼有人低估了這一點。在數據庫中有100K個表沒有理由。對於某些查詢，性能可能會更差。從元數據中讀取表的屬性將成爲MySQL中的一個大問題，例如，在這種情況下，信息模式的實現可能無法很好地執行。 – 2013-03-15 13:30:06

@ypercube這似乎很好，但我無法在他的發言中找到答案。 – Ambrose 2013-03-15 13:33:10

我沒有投票（我100％同意「不要這樣做！」），但我不太確定我同意第二個顯然更快。如果表格已正確索引，則每個查詢應能夠執行完全相同的讀取次數。還要考慮具有這麼多表的模式會產生很多其他開銷（權限檢查，列驗證等），這些開銷可能不會線性擴展，並且在正常模式中可以忽略不計。我只是建議不要以任何方式鼓勵這會更快，因爲我堅信它不可能。 – 2013-03-15 13:38:15

您關於第二個模式的問題是無關緊要或邏輯較少的，因爲您無法使用包含10000個記錄的10000個表來處理數據庫。您必須與架構1相關並顯示其中的一些邏輯。感謝

來源

2013-03-15 13:02:10 khush

不同的行而不是行

回答

相關問題