Bug #109079 InnoDB: The B-tree of index GEN_CLUST_INDEX is corrupted
Submitted: 14 Nov 2022 15:03 Modified: 13 Dec 2022 12:33
Reporter: Fabien Bagard Email Updates:
Status: Verified Impact on me:
Category:MySQL Server: InnoDB storage engine Severity:S4 (Feature request)
Version:5.7.39-log, 8.0.28 OS:Debian (Not tested on other OSes)
Assigned to: CPU Architecture:x86 (Not tested on other architectures)

[14 Nov 2022 15:03] Fabien Bagard
False report of a corrupted index. It can be GEN_CLUST_INDEX if the table has no primary key or PRIMARY index if the table has a primary key.

Without primary key defined we have `InnoDB: The B-tree of index GEN_CLUST_INDEX is corrupted` and key gets corrupted with "`h` char(237) NOT NULL"

With primary key : `InnoDB: The B-tree of index PRIMARY is corrupted` and key gets corrupted with "`h` char(238) NOT NULL"

Having one less CHAR somewhere in the table definition and key corruption is not reported anymore.

Doubling the number of CHAR and using UTF-16 does not cause the key corruption error message.

How to repeat:

  `a` char(255),
  `b` char(255),
  `c` char(255),
  `d` char(255),
  `e` char(255),
  `f` char(255),
  `g` char(255),
  `h` char(237)

INSERT INTO `A` VALUES ('','','','','','','','');

check table A;
[14 Nov 2022 15:07] Fabien Bagard
Error message in logs:

[ERROR] InnoDB: Field 3 len is 20, should be 1020; COMPACT RECORD(info_bits=0, 11 fields): {[6]      (0x000000000C04),[6]    `I(0x000000000009),[7]    '  (0x03000001070100),[0+20](0x)(0x000001040000000400000006000000000000030C),[1020]
[14 Nov 2022 15:19] MySQL Verification Team
Hi Mr. Bagard,

Thank you for your bug report.

However, this is not a bug.

It is fully explained in our Reference Manual, since this is InnoDB-specific feature.

Simply, the fixed size of the record is too big. You should convert many of those CHAR columns into VARCHAR.

Not a bug.
[13 Dec 2022 12:33] MySQL Verification Team

This change changes behaviour of our InnoDB storage engine. However, issuing a warning or error after CREATE TABLE statement would make lot's of sense .....

Verified as a feature request.