mysql重置auto_increment仅设下个值，需先清空数据；postgresql须重置序列；sql server用dbcc checkident；sqlite可update sqlite_sequence表。
MySQL 中用 ALTER TABLE ... AUTO_INCREMENT 重置自增 ID 有效，但只对下一条插入生效
直接执行 ALTER TABLE t1 AUTO_INCREMENT = 1 不会清空已有数据，也不会修改已存在的主键值；它只是把“下一个要分配的自增值”设为指定数字。如果表里已有 ID 为 100 的记录，而你设成 1，下一条 INSERT 仍会用 101（除非 1～100 全被删光了）。
常见错误现象：ALTER TABLE ... AUTO_INCREMENT = 1 执行成功，但新插入记录的 ID 还是 101、205 这类“跳号”，不是从 1 开始——说明表里还有数据占着位置，MySQL 会自动取当前最大 ID + 1 作为起点，覆盖你设的值。
- 必须先清空数据（
TRUNCATE TABLE或DELETE+OPTIMIZE TABLE），再改AUTO_INCREMENT -
TRUNCATE TABLE会重置计数器，且不可回滚；DELETE FROM不会，必须手动ALTER - MyISAM 和 InnoDB 行为一致，但 InnoDB 在未提交事务中可能缓存旧值，导致重置后首次插入略慢
PostgreSQL 没有 AUTO_INCREMENT，得操作序列（sequence）
PG 的自增本质是靠序列对象（如 t1_id_seq）驱动的，ALTER TABLE ... AUTO_INCREMENT 根本不存在，硬写会报错：ERROR: syntax error at or near "AUTO_INCREMENT"。
正确做法是找到对应序列并重置它：
SELECT pg_get_serial_sequence('t1', 'id');
拿到序列名后，用 ALTER SEQUENCE ... RESTART WITH 1：
ALTER SEQUENCE t1_id_seq RESTART WITH 1;
- 如果表刚建好还没插过数据，序列默认从 1 开始，无需重置
- 如果用
INSERT ... VALUES (nextval('t1_id_seq'))手动取值，重置后下次nextval()就是 1 - 用
serial或bigserial创建字段时，序列名固定为表名_字段名_seq，大小写敏感
SQL Server 的 DBCC CHECKIDENT 是唯一正解
SQL Server 不支持 ALTER TABLE ... AUTO_INCREMENT，也不管序列对象；它用 IDENTITY 属性，重置必须用 DBCC CHECKIDENT 命令。
常见错误：写成 ALTER TABLE t1 ALTER COLUMN id RESTART WITH 1 → 报错：Incorrect syntax near 'RESTART'。
- 重置为 1 并让下一条插入用 1：
DBCC CHECKIDENT ('t1', RESEED, 0)（注意是 0，因为 SQL Server 下次加 1） - 只查看当前种子值：
DBCC CHECKIDENT ('t1', NORESEED) - 如果表非空，
RESEED后插入可能冲突（比如已有 ID=1），需确保目标值不重复
SQLite 的 sqlite_sequence 表不能直接 UPDATE？其实是能的，但有前提
SQLite 把自增信息存在系统表 sqlite_sequence 里，字段是 name（表名）和 seq（当前最大值）。很多人试 UPDATE sqlite_sequence SET seq = 0 WHERE name = 't1' 失败，是因为没开写权限或表不存在。
关键点：
- 只有启用
autoincrement的INTEGER PRIMARY KEY字段才会在sqlite_sequence中有记录 - 执行前确认该表确实出现在
SELECT * FROM sqlite_sequence结果里 - 需要有写系统表权限（默认开启，但某些嵌入式环境可能禁用）
- 改完后立即插入，ID 就从 1 开始；不重启、不
VACUUM也生效
重置命令就是：UPDATE sqlite_sequence SET seq = 0 WHERE name = 't1';
重置自增 ID 看似一步命令，实际每种数据库背后机制完全不同；最常被忽略的是：重置操作本身不检查数据冲突，也不保证后续插入一定成功——你得自己确认目标值在表中不存在，否则直接报主键重复。
