我使用TopLink作爲我的ORM和MySQL作爲數據庫。現在我已將我的主鍵轉換爲GUID,如何修復性能?
我交易我的自動增量主鍵爲我的一個表的GUIDs(好吧,不完全是:我實際上使用一個隨機的64位整數,但這足夠滿足我的需要)。
無論如何,現在甚至不使用密鑰的查詢花費的時間更長。
我該怎麼辦?
我使用TopLink作爲我的ORM和MySQL作爲數據庫。現在我已將我的主鍵轉換爲GUID,如何修復性能?
我交易我的自動增量主鍵爲我的一個表的GUIDs(好吧,不完全是:我實際上使用一個隨機的64位整數,但這足夠滿足我的需要)。
無論如何,現在甚至不使用密鑰的查詢花費的時間更長。
我該怎麼辦?
如果您的表是由您查詢的字段索引的。密鑰的內容不應該有任何明顯的性能影響。他們可能還有別的東西。
我有一個代表creationDate的字段。我怎麼能強制我的表相應的索引? – carrier 2008-12-06 02:28:28
確保鍵列確實是PRIMARY KEY,因此也是聚集(物理)索引。
確保您的索引能夠處理您的常見查詢。
隨機整數?你意識到有可能擊中同一個pri鍵?
我有一個代表creationDate的字段。我怎麼能強制我的表相應的索引?
create index Table_creationDate on Table(creationDate);
如果你使用MySQL中all rows are referred to by primary key InnoDB表,所以如果您使用的是二次關鍵業績將受到影響。
您是否已將保證更改爲唯一的自動遞增主鍵值,以便生成重複的64位隨機值?爲什麼? – some 2008-12-06 02:10:52
那麼......要充分利用GUID提供的優勢。在我的情況下,如果發生重複,應用程序將再次嘗試。 – carrier 2008-12-06 02:27:03
這可能是有趣的:http://www.mysqlperformanceblog.com/2007/03/13/to-uuid-or-not-to-uuid/ – some 2008-12-06 03:34:49