mysql數據庫自增主鍵歸零（數據庫表主鍵自增）

本文目錄一覽：

1、MySql 設置ID主鍵自增,從0開始,請問怎麼設?
2、Mysql中刪除表數據且自增主鍵從1開始
3、mysql重置主表主鍵自增值
4、mysql 主鍵自增,刪除數據之後再次insert時id希望是能夠恢復到初始值
5、在mysql中要將id設置成自增並且要在前面自動補0，應該要怎麼實現啊？？

MySql 設置ID主鍵自增,從0開始,請問怎麼設?

就我所知這個好像無法實現，就算你自己編譯mysql恐怕也很難。因為last_insert_id()這個內置的函數返回最近一次插入的自增長ID，當沒有符合條件的ID時，它返回0，所以如果自增長從0開始的話，這個返回值就很難判定到底是插入了一條自增長ID為0的記錄還是沒有符合條件的記錄了。

Mysql中刪除表數據且自增主鍵從1開始

Mysql中想要刪除全部數據但保留表結構可以使用

若需要把自增主鍵重新恢復到從1開始，可執行如下命令：

mysql重置主表主鍵自增值

重置主鍵自增，前提是這個表中的數據必須清空。

如果清空後還是不能重置的，那麼刪掉表，重建。

mysql 主鍵自增,刪除數據之後再次insert時id希望是能夠恢復到初始值

可能的反方案：

需要找到系統表，查找到對應該表鍵對應的計數器，進行修改。

但這樣可能引起一系列的系統同步的問題。

如果系統沒有提供對自增加值的修改，還是不要改的好。

在mysql中要將id設置成自增並且要在前面自動補0，應該要怎麼實現啊？？

隨着 MySQL 8.0.16 的發佈，我們為 MGR 添加了一些功能，以增強其高可用性。其中一個功能是能夠在某些情況下啟用已離開組的成員自動重新加入，而無需用戶干預。

為了理解這個功能的好處以及如何使用它，我們將快速查看它背後的概念以及它首先存在的動機。

介紹

MGR 允許 MySQL 用戶輕鬆管理高可用組，並完成保證系統高可用所需的所有特徵，例如容錯或故障檢測。

MGR 中提供的基本保證之一是該組呈現給用戶的是一個不可分割的整體，這意味着一旦成員加入或離開該組，該更改將立即被其他成員得知。默認情況下，組內的數據本身最終是一致的，儘管可以被修改。為了實現這種保證，MGR 使用組成員服務，以及通過一致性算法檢測有衝突的事務並中止它們。MGR 的這一方面超出了本文的範圍，與成員自動重新加入功能並不完全相關，本文不作贅述。

組內新成員必須符合一些條件。其中新成員需要在事務方面趕上組進度（是通過選擇組內一個成員來將已處理的事務流式傳輸給他，在 MGR 中稱為「捐贈」）。最後，只要在此「分佈式恢復」過程中沒有遇到任何錯誤，組內新成員將被聲明為 ONLINE 狀態。

MGR 依靠組通信層 (GCS) 來管理組。該層實現了用於解決衝突事務的一致性算法，並強制執行一些通信特性。對於實現前面提到的組的不可分割視圖，這些特性至關重要，如消息的總順序、安全傳遞或視圖同步等。

GCS 需要能夠檢測組中哪些成員失效或看起來失效。一旦這些成員被檢測為失效，就將其從該組中移除，以便保持該組正常使用。為此 GCS 在每個成員中引入了一個故障檢測器，用於分析組內交換的消息。如果它在一段時間內沒有收到來自指定成員的消息，則故障檢測器將對該成員產生「懷疑」，並認為該成員可能已經失效。成員從「懷疑」到真正失效的等待時間是可以配置的。

重新加入成員存在的問題

我們已經了解 MGR 必須為了高可用提供的策略，以及它如何實現，接下來請看示例：

一個小組由三個成員組成，其中一個成員偶爾會遇到丟失數據包、斷連或者其它導致無法解決的錯誤情況的影響組內通信。還要考慮這些錯誤持續時間超過 group_replication_member_expel_timeout的值。

其中一個組員發生故障，小組的其他成員將決定踢出該成員。問題是，一旦該成員重新入組，他將被組驅逐加入失敗，需要通過手動干預。

如果該成員的驅逐超時屬性設置不為 0，則它將在被驅逐前等待滿足該時間量（將超時設置為 0 意味着他將永遠等待）。超時後成員將被驅逐並重新建立連接，並且無法重新加入舊組，需要再次手動干預。

於此，當存在網絡故障時，顯然需要手動干預。

在 MySQL 8.0.16 中，我們引入了自動重新加入組的功能，一旦成員被驅逐出組，它就會自動嘗試重新加入該組，直到達到預設的次數為止。有時每次重試之間至少等待5分鐘。

如何啟動自動重新加入？

可以通過將group_replication_autorejoin_tries設置為所需的重試次數來開啟並使用自動重新加入功能。

SET GLOBAL group_replication_autorejoin_tries = 3

默認值為 0，表示服務器禁用自動重新加入。

如何驗證自動重新加入？

與 MySQL 中的許多功能一樣，自動重新加入過程是可以監測的。自動重新加入的可檢測性依賴於性能模式基礎架構，階段式收集有關數據。

他們獲取以下信息：

事件發生的線程ID（THREAD_ID）

活動名稱（EVENT_NAME）

起止時間戳以及事件的總持續時間（TIMER_START，TIMER_END 和 TIMER_WAIT）

在事件停止之前完成的工作單位和預估工作單位（WORK_COMPLETED，WORK_ESTIMATED）

因此，當自動重新加入過程開始時，它將在performance schema中註冊一個名為「stage / grouprpl / Undergoing auto-rejoinprocedure」的事件。使用表performance_schema.events_stage_current， performance_schema.events_stages_summary_global_by_event_name和performance_schema.events_stages_history_long我們可以觀察到以下內容：

是否正在進行自動重新加入程序

到目前為止，已經減少重試的次數

直到下一次重試的估計剩餘時間

自動重新加入過程狀態

可以通過過濾包含「auto-rejoin」字符串的活動事件來查找自動重新加入過程狀態（即，是否正在進行）：

SELECT COUNT(*) FROM performance_schema.events_stages_current

WHERE EVENT_NAME LIKE ‘%auto-rejoin%’;

COUNT(*)

查詢結果存在，證明服務器上運行了自動重新加入過程。

到目前為止的重試次數

如果正在進行自動重新加入程序，我們可以通過選擇階段事件上的工作單元數來檢查到目前為止嘗試的重試次數：

SELECT WORK_COMPLETED FROM performance_schema.events_stages_current WHERE

EVENT_NAME LIKE ‘%auto-rejoin%’;

WORK_COMPLETED

在這個例子中，到目前為止只有一次嘗試。

預計到下次重試的剩餘時間

在每次重新加入嘗試之間，服務器將處於 5 分鐘的可中斷睡眠中。重新加入嘗試直到成功或失敗之間的時間是無法估計的。因此，為了粗略估計剩餘時間，我們可以將到目前為止嘗試的重試次數乘以 5 分鐘，並減去到目前為止的階段事件所花費的時間，以估計我們還需要多長時間：

SELECT (300.0 – ((TIMER_WAIT*10e-12) – 300.0 * num_retries)) AS time_remaining FROM

(SELECT COUNT(*) – 1 AS num_retries FROM

performance_schema.events_stages_current WHERE EVENT_NAME LIKE ‘%auto-rejoin%’) AS T,

performance_schema.events_stages_current WHERE EVENT_NAME LIKE ‘%auto-rejoin%’;

time_remaining

30.0

所以在這個例子中，在下一次重新加入之前還有 30 秒。注意性能模式表中的所有時間記帳都以微秒精度保持，因此我們將 TIMER_WAIT 縮放為秒。

使用自動重新加入與驅逐超時的權衡

到目前為止，在這篇文章中我們只關注自動重新加入。實際上，有兩種不同的方法可以實現離開組的成員的重新加入：

設置自動重新加入嘗試次數來實現自動重新加入

設置該成員的驅逐超時時間然後配合手動干預

能有延緩刪除組內可疑成員，並且如果配置為足夠長的驅逐超時時間，則增加了重新建立連接的機會，再次與組進行交互。

雖然這兩個功能實現了相同的目標，但它們的工作方式是不同的，並且需要權衡。通過使用驅逐超時，您可以維護組中可疑的成員，其缺點是您無法添加或刪除成員或選擇新的主機。如果通過使用自動重新加入，該成員將不再是該組的正常組員，將保持在 superreadonly 模式，直到重新加入該組。但在此期間，重新加入成員的同步舊數據的可能性將增加。自動重新加入過程可監控，而驅逐超時不是真正可監控的。

所以，總結一下：

驅逐超時的優點

– 該成員一直在該組內

– 可能更適合足夠小的網絡故障

驅逐超時的缺點

– 在懷疑某個成員時，無法在該組上添加/刪除成員

– 在懷疑某個成員時，無法選擇新的主機

– 您無法監控此過程

自動重新加入的優點

– 該組將在沒有重新加入成員的情況下運行，您可以添加/刪除成員並選擇新的主機

– 您可以監控該過程

自動重新加入的缺點

– 您增加了重新加入成員上過時讀取的可能性

– 可能不適合足夠小的網絡故障

總而言之，我從啟用自動重新加入中獲得了什麼？

通過啟用自動重新加入，您可以減少對MySQL實例的手動干預的需要。您的系統

更加適應瞬間網絡故障，同時滿足對容錯性和高可用的保證。

摘要

我們引入了一個名為group_replication_autorejoin_tries的新系統變量，允許用戶設置 MGR 成員在被驅逐或與組的大多數人失去聯繫後嘗試重新加入組的次數。

默認情況下，此自動重新加入過程處於關閉狀態。它能幫助用戶在面對瞬間網絡故障時避免對 MGR 成員進行手動干預。

原創文章，作者：簡單一點，如若轉載，請註明出處：https://www.506064.com/zh-hk/n/130360.html