我正在研究需要在MySQL表中保存頁面的每個視圖日誌的系統。如果訪問者在過去24小時內未訪問過該頁面，則該視圖將僅被記錄。我想知道如果這樣做會在性能和數據庫大小方面造成很大的問題。在每個頁面視圖中插入數據庫行
需要這樣做的網站平均每天約有60,000次獨特的綜合瀏覽量，因此每天新增約6萬個新行（每2秒鐘不到1個）。該表只有3列：i_id,ip_address,timestamp。 i_id是另一個表的外鍵。
表格將在每天結束時使用CRON腳本清除。
這樣做會不會有數據庫緊張？例如，如果網站的流量飆升（定期執行），則每天可能會觸發超過200,000次綜合瀏覽量，這意味着每秒超過2次查詢。
一般約定是在審計表上沒有約束條件（主要的，外部的等），當然不是索引 - 所有上述都會減慢插入。
批量插入將是工作考慮 - 批處理插入以降低數據庫所需的連接數量，操作涉及的時間量（一個vs多個）。此外，如果爲此寫入事務日誌 - 儘量減少寫入事務日誌，因爲如果希望能夠在某個時間點重新生成數據庫，則需要寫入IO以影響數據庫。
我沒有看到在一天結束時清除記錄 - 兩天內發生的流量怎麼樣？ MySQL partitioning would likely be a better idea。
你的問題不是每天瀏覽量。您必須考慮在高峯時段每秒需要瀏覽多少次綜合瀏覽量。如果瀏覽量均勻分佈，並且每秒只有2次綜合瀏覽量，那麼在平均非共享服務器中，這不會成爲問題。
但它無法確定沒有更多的數據，就像它是您使用，真正的頁面加載配送等
+1每秒查詢2次是完全不重要的負載。 –
假設數據庫也在爲網站提供內容，那麼比第二個/ etc中的統計信息插入要多得多。 –
硬件我覺得你應該：
'INSERT DELAYED'可能不適合在此處進行日誌記錄，他需要插入的行才能立即對其他會話可見，以防止發生下一次插入 - DELAYED INSERT不會給予任何時間保證 – Crack
唯一鍵和INSERT DELAYED IGNORE應該修復此問題問題。 –
爲什麼使用我的ISAM？它鎖定整個表達到插入意義插入不能同時發生。 InnoDB使用行級鎖定。 –
只要確保您的表具有適當的選擇索引。數據庫管理系統可以承受的遠不止這些。
審計表通常是大量插入/等，低讀取，所以索引中很少或沒有值。並且索引減慢插入... –
如果John想要檢查給定的用戶是否最近訪問了他的網站，並且我沒有看到通過cookie完成的指示器，那麼他們是必需的 – Crack
你可能會想要確保你的mysql集羣已經過優化，並且可能會有壓力，只要確保它可以爲這樣的命中做好準備。
幾點意見：
清除記錄的要點是，那麼他們將被提交到一份報告中，並且之後將不再需要他們。 – John
@John：這是你的系統，但能夠按月份，年份，時間進行聚合將爲你的系統提供更多的價值。 –
那麼，這取決於我認爲的系統：P但是在這種情況下，確實沒有必要在一天後保留數據。謝謝！ – John