I haven't tested this (as my tables usually have at least a primary key) but I expect the difference to depend on the choice of the primary key.
Based on the information in MySQL documentation about InnoDB engine, all InnoDB tables have a clustered index. This is the
PRIMARY key of the table and in lack of one, the first
UNIQUE index. And in lack of unique keys as well, a hidden column is created (and values are auto-generated for it) and used internally for unique identification and for clustering.
The "key" here is that this hidden column is a 6-byte integer column. So, you have 6 bytes per row overhead when you don't define primary and any unique index in an InnoDB table.
In contrast, if you have a narrower column (like a 1, 2, 3 or 4 byte integer auto-incrementing column) defined as primary or unique index , you should expect an improvement on
If you define an 8-byte integer I'd expect a decrease on efficiency.
If it is a
VARCHAR(20) or a wider combination of column, the decrease would probably be worse, depending on the order you provide the PK values. Auto-incrementing values are by definition increasing (so good for a clustered index). If you provide non-increasing values, that will affect the
INSERT efficienct negatively.