Size of record pointer in InnoDB?
MyISAM defaults to 6 bytes for a data pointer in an index.  And defaults to 5 bytes for index pointers.  The "6" you are referring to is a byte offset from the .MYI file into the .MYD file.  That is not necessarily relevant to the rest of your question.

InnoDB is much more complex.  It does not use pointers, only columns.

The data is stored in a BTree that is ordered by the PRIMARY KEY.  (Actually a B+Tree.)

A secondary index is stored in a separate BTree that has the PK in each node record.

FKs are simply the indicated column(s), and are used to do a lookup in a suitable index in the other table.

id TINYINT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY


takes 1 byte, plus some overhead

id VARCHAR(255) CHARSET utf8mb4 PRIMARY KEY,
stuff1 VARCHAR(255) CHARSET utf8mb4,
stuff2 VARCHAR(255) CHARSET utf8mb4,
INDEX(stuff1, stuff2)


This last secondary index takes up to 3*(2+255)*4+? bytes --


3 columns (stuff1, stuff2, id)
2 -- length
255 -- max length in characters for utf8mb4
4 -- max bytes/character in utf8mb4
+? -- There is overhead; this varies.


Back to "pointers".  There are some "pointers" at lower levels:


4 byte block pointer (16KB blocks), hence a limit of 64TB on table size.
20 byte pointer to overflow data (used to point to the 'rest' of a large TEXT or BLOB.
Some 1-byte and 2-byte lengths or pointers inside a block.
? bytes for a transaction id.  (See MVCC, etc)


As a Rule of Thumb, an InnoDB table takes 2-3 times the disk space as the equivalent MyISAM table.


  So what is the size of pointer to a tuple in InnoDB Mysql systems?



If TINYINT UNSIGNED suffices (up to 255 items in the other table), then think of it as 1 byte in each table, plus 1 byte for each secondary key in the target table.
INT is often used (with a usually more-than-adequate 2-billion limit), think of it as 4 bytes each.


Perhaps a more important question is whether to have a 'surrogate' (AUTO_INCREMENT) id on a table.  Count the number of references in this table and from other tables to judge its bulk.  And use the smallest flavor of INT that will be safe.

That brings up "burning" of ids.  In almost all cases, INSERT (and its variants) will first allocate the auto_inc ids that it might need.  If it does not use them all (eg for INSERT IGNORE), the ids are lost (burned).  This can lead to using up, say, TINYINT much faster than anticipated.  For bulk normalization, I provide this technique:  http://mysql.rjweb.org/doc.php/staging_table#normalization