[dev.mysql.com...]

To add another layer of confusion to potential reverse engineers, swap around some of the bytes when displaying publicly.

uuid() would suffice but it takes 128 bits storage.

If that's to long then your best generating a random int and testing for uniqueness. If you do this in a procedure you only need to make one call to the server.

If you're using this field as a key in other large tables then that's another good reason not to an int instead of uuid. Sometimes you might want to use an autoincrementing int for your primary key and uuid which is only visible to users.

I'd also prefer to use auto-increment myself. Assuming a 4 byte ID, to prevent 'number of rows known to public user' I'd put the 4 bytes in a haystack of 16 bytes or so, and do some bitwise shifting to hide the ID from view, but it'd be much easier to code in something like PHP rather than a MySQL procedure or UDF.

I guess it depends how much of a necessity it is to hide them. Something simple like this hides it from being obvious, but anyone who wants to take a greater interest could relatively easily reverse engineer it. Convert base 10 to arbitrary base.
mysql> SELECT CONV(12345,10,33);
+-------------------+
| CONV(12345,10,33) |
+-------------------+
| BB3 |
+-------------------+
1 row in set (0.00 sec)

mysql> SELECT CONV('BB3',33,10);
+-------------------+
| CONV('BB3',33,10) |
+-------------------+
| 12345 |
+-------------------+


Doing REVERSE(CONV(12345,10,33)) and REVERSE(CONV(54321,33,10)) makes it a little less obvious. You could keep adding functions to get it to the point where it's not obvious that it's an auto-increment value, but is still able to be converted without a reference table.

Using something time related also makes a lot of sense, to avoid collisions.