[Bug]: CLONE does not preserve AUTO_INCREMENT state

[Ariznawlll]

Environment

• Branch: main
• Commit: 1d7b6311ce91df0968da435bb405f3d68137c595
• Fresh standalone MatrixOne on macOS arm64

Reproducer

DROP DATABASE IF EXISTS clone_ai;
CREATE DATABASE clone_ai;
CREATE TABLE clone_ai.src (
  id BIGINT AUTO_INCREMENT PRIMARY KEY,
  v INT
);
INSERT INTO clone_ai.src(v) VALUES (10), (20), (30);

-- Table clone variant
CREATE TABLE clone_ai.dst CLONE clone_ai.src;
INSERT INTO clone_ai.dst(v) VALUES (40);

SELECT
  (SELECT AUTO_INCREMENT FROM information_schema.tables
    WHERE table_schema = 'clone_ai' AND table_name = 'src') AS source_next,
  (SELECT AUTO_INCREMENT FROM information_schema.tables
    WHERE table_schema = 'clone_ai' AND table_name = 'dst') AS clone_next,
  (SELECT MAX(id) FROM clone_ai.dst) AS clone_inserted_id;

Actual result

The table-clone reproduction was run with three independent databases. Every run produced:

source_next | clone_next | clone_inserted_id
4           | 10002      | 10001

The same result occurs through CREATE DATABASE clone_ai_dst CLONE clone_ai_src: each of three independent runs retained IDs 1,2,3, but the destination's first inserted row received ID 10001.

A non-clone control with the same table and initial three inserts assigns ID 4 to the next row.

Expected result

The clone should preserve the source table's auto-increment continuation state. With source metadata reporting AUTO_INCREMENT = 4, the first subsequent insert in the cloned table should receive ID 4, as it does in the non-clone control.

Impact

Every cloned auto-increment table deterministically creates a 9,997-value gap for the first post-clone insert. This changes application-visible identifiers and breaks workflows that expect clone data plus its subsequent write behavior to match the source state.

[Ariznawlll]

Additional confirmation: the defect is independent of copied data volume.

For three independent empty-source table clones:

source_next | clone_next | clone_inserted_id
1           | 10002      | 10001

Each source table was only id BIGINT AUTO_INCREMENT PRIMARY KEY, with no inserted rows before CREATE TABLE dst CLONE src. This rules out a collision-avoidance explanation based on copied IDs: cloning even an empty table skips the initial 10,000-value allocation range.

[Ariznawlll]

The same state loss affects table-level Data Branch creation.

For three independent runs:

CREATE TABLE src(id BIGINT AUTO_INCREMENT PRIMARY KEY, v INT);
INSERT INTO src(v) VALUES (1), (2), (3);
DATA BRANCH CREATE TABLE dst FROM src;
INSERT INTO dst(v) VALUES (4);

Every run produced:

source_next | branch_next | branch_inserted_id
4           | 10002       | 10001

Thus the defect is shared by ordinary table CLONE, database CLONE, and DATA BRANCH CREATE TABLE; a fix should cover the common clone path rather than only the SQL spelling.

[gouhongshen]

PR #27154 is trying to fix this issue.