跳到主要內容

發表文章

目前顯示的是有「innodb」標籤的文章

[野人獻曝] 千萬不要在 MySQL 內有用到 auto_increment 的表下 INSERT ... ON DUPLICATE

原因很可怕,所以不要問! 最近開了一個有 auto_increment 欄位的資料表, 並且將該表中幾個欄位設為唯一值索引, 然後就下了以下的SQL塞資料: INSERT INTO EXAMPLE (a, b, c) VALUES ('1', '2', '3') ON DUPLICATE KEY UPDATE d = '4' 結果發現 auto_increment 欄位中的值越變越大, 不過一千多筆的資料,流水號卻取到七萬多。 看了 MySQL 的說明 , 才發現下 INSERT ... ON DUPLICATE KEY 時碰到 auto_increment 欄位時, 流水號也會持續增加(只有 Update 時才不會增加), 所以下一次真的有新增資料時,流水號會跳得老遠去...... 當下只好照 StackOverflow 上的一篇回覆 修改程式碼解決這個不算大卻有點微妙的問題......

[野人獻曝] 救回使用 innodb 的 mySQL

因為一連串的原因(不要問很可怕), 導致我的 mySQL 整個重啟不能, 好死不死的又因為我資料庫裡面的資料表恰好都是 innoDB, 因此問題更難搞。 經過該死的 Google 和實驗後, 總算找到一個勉強算是救回資料的方法! 方法如下: 無論如何先把 mySQL 先停掉 停掉之後在你的 mySQL 設定檔中加上一行 innodb_force_recovery = 4 * 重新啟動 mySQL,試試看是否可以連進 mySQL,確定可以連進去後,先把所有會寫入 DB 的程式都先關掉,然後開始備份資料。 資料備份完後,請把有用到 innodb 的資料庫砍掉。接著移除上面那行 innodb_force_recovery,並且刪除 /var/lib/mysql 下所有 ib 開頭的檔案,然後重新啟動 mySQL。 接著重建資料庫,並把備份資料匯入應該就可以讓 mySQL 正常運作了。 * 參閱: Forcing InnoDB Recovery