This paragraph from the "Changes in MySQL 8.0.16" page (https://dev.mysql.com/doc/relnotes/mysql/8.0/en/news-8-0-16.html) looks interesting:

Incompatible Change: In MySQL 5.7, specifying a FOREIGN KEY definition for an InnoDB table without a CONSTRAINT symbol clause, or specifying the CONSTRAINT keyword without a symbol, causes InnoDB to use a generated constraint name. That behavior changed in MySQL 8.0, with InnoDB using the FOREIGN KEY index_name value instead of a generated name. Because constraint names must be unique per schema (database), the change caused errors due to foreign key index names that were not unique per schema. To avoid such errors, the new constraint naming behavior has been reverted, and InnoDB once again uses a generated constraint name.

For consistency with InnoDB, the NDB storage engine now uses a generated constraint name if the CONSTRAINT symbol clause is not specified, or the CONSTRAINT keyword is specified without a symbol. In NDB releases based on MySQL 5.7 and earlier MySQL 8.0 releases, NDB used the FOREIGN KEY index_name value.

The changes described above may introduce incompatibilities for applications that depend on the previous foreign key constraint naming behavior. (Bug #29173134)

Although, as we're using InnoDB and not NDB then it appears as though they've reverted the new 8.0 behaviour back to 5.7 behaviour as of 8.0.16 - confused :~]

Thanks for those details. I'll try to debug this.

I assume that ColumnOrderedKey is used regardless of the number of columns in the index. i.e. it is used for single key indexes as well as composite key indexes.

I base this assumption on the table involved in the above exception having no composite key indexes in either the meta data nor the existing table: just three single key indexes: primary key, an index on a foreign key and an index on the classid column (discriminator column).

If the index name in the existing database was different to what is expected by DN would that cause this type of issue? I wonder if the algorithm used for forming the index name could have different behaviour under the new MySQL 8.x JDBC driver (Connector/J) or MySQL 8.x database.

Sets the relative position of a column that is part of an index. So if you have a composite index formed of two columns, the index behaves differently dependent on the ordering / position of columns.

CREATE INDEX i1 ON t1 (col1 ASC, col2 DESC);

Debug what MySQL JDBC driver is returning from the getIndexes call (i.e what info TableImpl.getExistingIndices has available to it), how many columns in the index, their positions, their ordering etc.