The real effect of allowing two alphanumeric characters to lead off your PK is that you cannot store the PK in 32 bits any more, you need 48. (Six bytes instead of four.) However, the two-byte difference has to be taken with a grain of salt because of the structure of the index and its overhead. The pointers to the rest of the DB are also 32-bit integers. The code that defines the key structure and the item that identifies the key size take up room, too. This has the effect of making the buffer used to read in the key be able to hold fewer keys at a time, on the order of about 15% fewer, maybe.
What does this mean in practical terms? On modern computers, you can probably do 20-30 disk reads in a second when your machine is stand-alone and not time-sharing with other tasks that might use the disk. If you can store, say, 100 keys in a buffer and your table size is 3000 records, this takes 30 read operations to search the whole index. However, the expectation value is 1/2 the table has to be searched for random requests. So that means it takes 1/2 a second to find the key you want. And it takes 15% more when you changed sizes, so instead of 0.50 seconds, it takes 0.58 seconds roughly. Now, if you had 30,000 records, that means it might take between 5 and 6 seconds for the search. Closer to 5 with the integer key. Closer to 6 with the mixed key.
Bottom line, it is no big deal. One extra second at about the 30,000 record total population mark. Is that a small enough difference for you?
