我做了一個測試，看看是否劃分索引大表會提高性能。MySQL：分表後測試性能
原始圖表：20000行。 子表格：4x5000行。
主表分爲4個表，所有表都被索引，在測試中每個sql查詢在一個循環中被執行10000次，以測量更準確的查詢時間。
當我搜索表中的索引列時，我看不到性能上的差異，原始（20000行）表和新（5000行）表的查詢時間相同。
我試着通過刪除所有表的索引來進行相同的測試，並且性能差異很明顯，其中在子表中搜索比在大表中搜索快6倍。但索引的性能是一樣的。
那麼你認爲把我的桌子分成小桌子是浪費時間嗎？
注意：20000大小隻是爲了測試，我的真實數據將是100M或更大的大小。
是的，這是浪費時間。數據庫可以輕鬆處理數百萬行，而20,000則相對較小。正如您注意到的那樣，索引可以快速查找數據在大多數情況下，數據的大小並不會顯着影響查找的速度。查詢可能需要幾毫秒，如果大小的差異是100或1000倍，但您正在處理的比例不會產生真正的差異。
我的示例表僅用於測試，我的真實數據將達到100M行或該範圍內的某些內容。如果你的觀點差不多是100倍1000倍，那麼分割策略將是一種浪費，因爲我不會把我的桌子分成100張桌子！ – DeepBlue
@ user2007059這和你必須知道要查找哪個表，這將是更多的代碼，它不會有一個「好」的方式來知道它需要哪個表。 –
你已經有效地完成了改造Partitioning of Tables。我不會使用你自己的子表方案，並且專注於使用分區表將自動意味着使用內部子表，並且如果適當地制定了SQL，如果不需要，子表會自動從操作中排除。
但是，分區的所有管理都在服務器本身上，以便您的客戶端代碼可以保持簡單，並且您仍然只需處理單個表。
表結構應該根據應用程序的需求以及邏輯意義來確定。尤其是在20,000張已經很小的記錄表上。 （行大小的限制是65,535字節，所以即使你認爲數據大小不是那麼多） – 2013-02-04 17:22:26
這是浪費時間！ – newtover
樣本表是用於測試的，實際數據會比這個大得多。 – DeepBlue