MariaDB插入报错SQL Error(1467)：自增值读取失败求助

你遇到的这个错误通常和自增计数器的存储异常、表损坏或者存储引擎的底层逻辑有关，结合你提到的MariaDB 10.2.12版本、表字段差异的情况，除了重置自增值，试试这些具体的排查步骤：

1. 强制存储引擎重新计算自增计数器 #

不同存储引擎对自增计数器的存储方式不一样，先针对你的表引擎做对应操作：

• 如果是InnoDB：InnoDB的自增计数器存在内存中，有时候内存中的值会和实际数据脱节。你可以先把自增值设为1，让InnoDB自动扫描表找到最大ID再+1，纠正计数器：

  ALTER TABLE your_table_name AUTO_INCREMENT = 1;
  

  之后再设置回你需要的起始值（比如16），这样应该能修复内存中的异常值。
• 如果是MyISAM：MyISAM的自增计数器存在.frm文件里，要是这个文件损坏就会读取出错。可以备份后重建表：

  -- 先创建结构相同的新表
  CREATE TABLE new_table LIKE your_table_name;
  -- 迁移数据
  INSERT INTO new_table SELECT * FROM your_table_name;
  -- 替换原表
  DROP TABLE your_table_name;
  RENAME TABLE new_table TO your_table_name;
  

2. 检查并修复表损坏 #

自增读取失败很可能是表本身有损坏，先执行完整检查表命令：

CHECK TABLE your_table_name EXTENDED;

如果输出里有报错，就进行修复：

• MyISAM直接用：REPAIR TABLE your_table_name;
• InnoDB的话，需要先在my.cnf（或my.ini）里添加innodb_force_recovery=1，重启MariaDB后再尝试修复，修复完成后记得把这个参数改回去再重启，避免影响正常功能。

3. 排查BIGINT字段定义的隐性问题 #

你提到这个表的自增字段是BIGINT(19)，其他表是BIGINT(20)。虽然显示宽度本身不影响存储范围，但还是要确认几个点：

• 先看字段是不是无符号的：执行SHOW CREATE TABLE your_table_name;，如果是BIGINT(19) UNSIGNED AUTO_INCREMENT，那它的最大值就是你看到的18446744073709551615，要是之前计数器不小心跑到这个值，就会溢出报错。不过你已经改回16了，可能不是这个原因，但还是要确认实际数据的ID有没有接近最大值。
• 尝试把字段显示宽度改成20，和其他表一致：

  ALTER TABLE your_table_name MODIFY COLUMN id BIGINT(20) UNSIGNED AUTO_INCREMENT;
  

  旧版本的MariaDB偶尔会有显示宽度相关的兼容小问题，改一致说不定能解决。

4. 检查MariaDB 10.2.12的已知bug #

MariaDB 10.2.x的早期版本确实存在一些自增相关的bug，比如批量插入、事务回滚后计数器异常的情况。你可以去MariaDB的官方bug库搜10.2.12的自增相关问题，要是确认是bug，最稳妥的办法是升级到10.2系列的稳定版（比如10.2.44，是10.2的最后一个维护版本），或者用临时操作规避（比如每次插入前手动指定ID）。

5. 确认磁盘空间和文件权限 #

别忽略基础问题：如果服务器磁盘满了，或者MariaDB进程对表的物理文件没有读写权限，也会导致存储引擎读不出自增计数器：

• Linux下用df -h看磁盘剩余空间，Windows直接看磁盘属性；
• 检查表文件的权限，比如InnoDB的.ibd文件、MyISAM的.MYD/.MYI文件，确保mysql用户有读写权限：

  ls -l /var/lib/mysql/your_database_name/your_table_name.*
  

6. 手动插入指定ID的记录测试 #

试试手动插入一条带指定ID的记录，触发自增计数器更新：

INSERT INTO your_table_name (id, other_column) VALUES (16, 'test_content');

如果这步成功，再插入一条不指定ID的记录，看是否自动用17作为ID。要是成功了，说明自增计数器已经恢复；要是还是报错，大概率是存储引擎的底层问题，可能需要进一步排查引擎的日志。

内容的提问来源于stack exchange，提问作者Jeff