Eles estão certos. Juntar-se a um campo de texto CHAR(30) - particularmente um contendo dados de nome de pessoa - será lento, extremamente ineficiente e incrivelmente frágil. As pessoas mudam seus nomes (casamento é o exemplo óbvio), e várias pessoas podem ter o mesmo nome.

Você deseja criar índices apropriados em suas tabelas para dar suporte à ordem em que deseja que os dados apareçam e esquecer o clustering. Seu procedimento de otimização de desempenho parece um desastre procurando um lugar para acontecer. Desculpe, mas descartar/criar as tabelas como essa está causando problemas.

Eu começaria com um UNIQUE INDEX em customer.id, um UNIQUE INDEX em transaction.ticket_number e um INDEX (para desempenho em vez de cardinalidade, portanto, impor exclusividade não é muito importante) em transações (id, ticket_number DESC) e tomá-lo de lá. Os dados são retornados da tabela de transações na ordem em que aparecem no índice.

Eu só consideraria o clustering quando todas as outras vias de otimização de consulta estivessem esgotadas.