I would like to make a case for BIGINT, converting ISBN-10 (which has a non-numeric check digit 1/11th of the time) to ISBN-13 before storing.

That will take eight bytes, whereas ISBN-10 will take ten bytes and ISBN-13 will take 13 bytes. With typical word-boundary padding, either ISBN will probably wind up taking 16 bytes.

The memory requirement isn't terribly important, but there may be a noticeable speed penalty to using a CHAR field.

Modern architectures can handle BIGINT math directly with one extra memory fetch. This means that searching and sorting will be faster. Put an index on that column, and it will be faster still. In fact, I use ISBN-13 as my primary key in my MariaDB Library database.

When I changed it from CHAR to BIGINT, I noticed about a 20% performance improvement.

Another nice thing about proper ISBN-13 is you don't have to concern yourself with leading zero-padding. I even found some some SQL code to validate the ISBN-13 check digit.