UUIDBinaryType is the default mapping for UUID attributes (UUID->BINARY). So I would assume that the dialects for both H2 and MySQL pick that up (pgsql dialects e.g. map UUID differently). Is that what you see?

To be honest I am surprised that this happens with find as described. In fact I am not sure I believe that. I guess you probably mean that you see: WHERE id=? and then binding the UUID value with dashes. But even that I am surprised by. We'd simply bind the UUID as binary data. Maybe you are confusing the logging for what actually gets sent to database? I.e.:

10:47:46,750 TRACE BasicBinder:65 - binding parameter [1] as [BINARY] - [42d1330d-69ea-41c7-a980-c0f74ad7d44f]

For what it is worth that logging comes from a test that uses exactly the mapping you claim "fails", but the test is perfectly fine. Granted it uses H2 as the back end, but I simply do not see the fundamental difference using MySQL here. Maybe the BINARY(255) comes into play, but that would simply cause no matching I would think if anything.

So assuming you do see an actual failure, I am going to need a test showing that. The test I used is org.hibernate.test.id.uuid.interpretation.UUIDBasedIdInterpretationTest. The output is:

10:47:46,612 DEBUG SQL:92 - 
    create table UUID_ID_ENTITY (
        id binary not null,
        primary key (id)
    )
10:47:46,748 DEBUG SQL:92 - 
    select
        uuidbasedi0_.id as id1_0_0_ 
    from
        UUID_ID_ENTITY uuidbasedi0_ 
    where
        uuidbasedi0_.id=?
10:47:46,750 TRACE BasicBinder:65 - binding parameter [1] as [BINARY] - [42d1330d-69ea-41c7-a980-c0f74ad7d44f]

Which looks perfect.