MySQL auto Increment id 已採用但似乎未寫入磁碟
MySQL 有一個非常奇怪的問題，我們無法弄清楚。所以我需要專家的建議來找出嚴重的問題。我試圖提供所有可能的細節。但如果您需要更多資訊，您可以要求更多。
我們在另一個數據庫中有一個 MySQL 表（票證），該表通過觸發器從其他一些數據庫表（應用程序數據庫）中插入記錄。在繼續之前，讓我介紹一下數據庫設計和表結構。
我們有超過 600 個數據庫表，其表架構與 InnoDB 引擎相似。
數據庫
db_20110624
db_20110706
db_20110825
等等….600+
和日誌數據庫
我們將 after_insert 和 after update_trigger 寫入應用程序數據庫表。因此，只要從應用程序端插入/更新任何記錄，我們就會在 logdb.tbl1 表中獲得跟踪。（我們正在管理票證基礎隊列以進行進一步處理）
關於 logdb.tbl1 的資訊
我們在此表中缺少大約 3 到 4 條記錄/天目前記錄在表 12,273,398（1200 萬）中，我們定期從表中清除 1 個月前的數據，但自一個月或 15 天以來，我們沒有清除它。
表結構：
'serialid', 'bigint(20)', 'NO', 'PRI', NULL, 'auto_increment' 'requestunkid', 'bigint(20)', 'NO', 'MUL', NULL, '' 'fordate', 'date', 'YES', '', NULL, '' 'databasename', 'varchar(255)', 'YES', '', NULL, ''問題
我們在另一台伺服器上有一個程序，它從 logdb.tbl1 程序中選擇數據並將這些行插入另一台數據庫伺服器。
我們從tickets.channelupdates 中挑選限制為100 的數據並插入到另一個數據庫伺服器。為了跟踪待處理隊列，我們從另一個數據庫伺服器中找到 max(serialid)，並從 ticket.channelupdates 中選擇接下來的 100 條記錄。有時它會跳過一些要選擇的記錄。
例子：
| logdb.tbl1 | serialid 78887794 78887795 78887796 78887797 78887798 78887799 78887800 78887801 78887802 .......但是當我們執行 select 時，它會給出一些缺失行的結果。（例如，它給出 78887794,78887795,78887796,78887800,78887801,78887802）這裡 78887797 到 78887800 條記錄失去。但是當我們在一段時間後使用最大數量執行相同的查詢時……它給出了準確的結果。這對我們造成了非常嚴重的問題。由於這種差異，一些記錄被跳過。
注意問題是隨機的。這在 15 到 20 天后經常發生。此外，我們注意到插入（到 tbl1 表）和選擇（從 tbl1 表）之間有 1 秒到 15 秒的間隔。
我在這裡先向您的幫助表示感謝。
我們終於能夠找出問題所在。這是因為儲存過程中的以下語句。我們正在使用儲存過程插入記錄。問題是在 START 和 COMMIT 之間發生了很多事情。並且當任何插入發生在另一個表中時，它會保留自動增量 ID。但在它送出之前不要將其寫入磁碟。在寫入磁碟的下一個 id 之間，該程序的執行時間比前一個程序早。所以現在最大數量差異開始了。
**開始交易；
…..
犯罪;**
請提供所涉及的模式以及 SQL 語句。
一個瘋狂的猜測是您正在使用
OFFSET（或LIMIT nnn,mmm）。我在這裡解釋為什麼OFFSET可以跳過或重複行。