我正在尋找跟蹤大量開/關的最佳，最可擴展的方法。開/關適用於項目，編號從1到約6千萬。 （在我的情況下，開/關是否會員的書已被編入索引，是一個單獨的過程。）在沒有索引表的情況下跟蹤開/關
開/關必須通過項目編號快速搜索。他們不斷變化，所以重新索引成本不可能很高。新項目不經常添加到表格末尾。
想法解決方案，我認爲是一個僅索引表 - 一個表中每個字段都是主鍵的一部分。我收集ORACLE有這個，但沒有MySQL的引擎。
如果我使用MySQL，我認爲我的選擇是間：
兩個字段表 - 項目和「開/關」字段。更新將使用UPDATE進行處理。
一個字段表 - 該項目。在桌上意味着「在」。使用INSERT和DELETE處理更改。
我對其他技術開放。將所有東西按位存儲在文件中？
您可以通過使用選項＃1來獲得更大的靈活性，但兩者都可以有效地工作。但是，如果速度是一個問題，您可能需要考慮創建一個在MySQL啓動時預填充並在其他進程中原位維護的HEAP表。另外，在表中使用int和枚舉字段類型。由於它將全部保存在內存中，所以它應該閃電般快速，並且由於表格中沒有大量數據存儲，所以6000萬條記錄不應該成爲一個巨大的負擔，而且是記憶方面的。如果讓我來粗略估計：
INT（8）（增長，假設你會超過1億個的記錄一天）
枚舉（0,1）
那麼我們再來一輪高達每10個字節記錄：
10 * 60000000 = 6億
這是約572 MB的數據價值，再加上指數和額外的開銷，所以讓我們粗略地說..一個600 MB表。如果你在服務器上有這樣的內存空間，那麼一個HEAP表可能就是要走的路。
嘿約翰！對。我想我可能通過memcached來完成閱讀部分的工作。這些項目總是屬於同一個用戶，因此大多數時間將所有用戶圖書的開/關狀態存儲在單個memcached密鑰中。但數據需要永久存在。目前UPDATE命令正在查殺服務器。我認爲這是因爲該領域只是大型排隊結構中的衆多領域之一。 – LibraryThingTim 2011-05-05 02:07:38
您是在談論用戶何時開啓/關閉他們的書嗎？ – John 2011-05-05 02:17:56
如果您使用的是InnoDB，那麼6000萬行帶有ID和開關位的應該對MySQL沒有任何問題。
我有一個InnoDB表，可以跟蹤用戶已閱讀哪些論壇主題以及他們閱讀了哪些帖子。它包含2.5億行，14個字節寬，並且不斷更新......現在它正在做50個更新，現在是午夜，所以高峯時間可能是100-200 ?.
插入後索引列本身不會更新。主鍵是（user_id，topic_id），並通過使用INSERT ... ON DUPLICATE KEY UPDATE來添加新的last_read信息。
我經常測量，我沒有看到任何爭用或性能問題，但我在memcached中做了很多緩存讀取，因爲決定何時過期緩存非常簡單。我一直在考慮用戶爲了保持增長而對用戶進行分片，但我甚至不會費心將它存儲在MySQL中。
我對其他技術開放。將所有東西按位存儲在文件中？
Redis將是一個很好的選擇。特別是其sets和sorted sets將努力爲這個（如果你需要抓住一個範圍內使用除項目ID以外的東西值排序集也許是好的 - 像上次更新時間）
Redis的可能是值得一試，如果你還沒有 - 它可以是依賴於MySQL的應用程序的一個很好的補充，你可能會發現它的其他用途，它可以簡化你的生活。
關於LibraryThing的討論：http://www.librarything.com/topic/115692 – LibraryThingTim 2011-05-05 01:53:34
MySQL只支持索引表。 create table indexed_books（id int primary key）engine = innodb; – 2011-05-05 08:58:35