在MySQL中通過散列優化搜索

我有一個有很多字段的InnoDB表，其中一個是32字節（典型的md5結果）的唯一散列。在MySQL中通過散列優化搜索

我必須做很多查詢通過散列搜索的，但我的表開始要大（500.000記錄），而這個搜索需要大量的時間：

SELECT id FROM `table` WHERE `key`='Bj8DzS7RmCG41nLdgOp0kEhNtrfPo3KF'

這花了大約0.7秒

我可以創建這個「散列」32字節varchar列的索引，但是這個表增長很多，如果我必須優化表（重新索引），它需要很多時間來做到這一點（在我的情況下大約10分鐘），鎖定所有其他實時查詢。

那麼，什麼是最好的方法來優化查詢，你必須通過一個32字節的varchar字段進行搜索？

來源

2013-09-30 user2830719

我不明白你爲什麼重新編制索引。問題似乎在這裏，索引該欄是唯一合理的答案。 –

因爲每個重新索引需要大約10分鐘！每天大約有10,000個新的行......所以每天重新編制索引（例如凌晨3點）會很好......但我不想在重新索引時將表鎖定10分鐘。 – user2830719

您需要一個簡單的索引。

另外，你提到varchar，但你的列不是可變長度，所以char（32）會更合適。

如果您擔心在插入新行時維護索引的成本，則可以將表分區爲更小的塊。例如，你可以根據散列的第一個字符有16個獨立的表，例如table_0，table_1 .... table_f - 現在每個表只包含30,000條記錄。或者你可以在前兩個字符上劃分256個表格。

雖然您可以手動執行此操作，但結帳MySQL's built in support for partitioning too。

來源

2013-09-30 11:45:03

嗨Paul ... char（32）是一個很好的提示...另一方面，當我達到百萬條記錄時，表格分割將再次無用......我的關注點更多地是關於「重新索引」時索引隨着時間變得「老」... – user2830719

該索引不會變老，您只需重建它即可獲得一些性能優勢。請注意，在InnoDB上使用OPTIMIZE TABLE可能不是最快的方法 - 刪除並重新創建索引可能更有效 - 請參閱http://www.mysqlperformanceblog.com/2010/12/09/thinking-about-在您的innodb-table-stop上運行優化/ 請注意，分區仍然可以幫助您，因爲您只能在任何時候鎖定行的1/16（或1/256）。 –

Paul，沒關係......但我不想在任何情況下鎖定表格。我不能允許它。我會做一些測試。謝謝 – user2830719

在MySQL中通過散列優化搜索

回答

相關問題