MYSQL primary key strategy for microservices architecture
Corrected:

with MySQL You can store GUID/UUID data as char/varchar in case of UUID() and UNSIGNED INTEGER in case of UUID_SHORT()

My personal vision - UUID_SHORT not working case, it is unsigned INT same as Auto-Increment and You can read restrictions in function description.

UUID() will return result as utf8 string - "eabd691c-b552-11e6-942e-ee8ae5dda6a8"

Business logic for primary key - work well, You always mange this process and do not need spend time for call function.

add after question in comment:

performance not depend from business logic or auto increment, it depend mostly from 2 parameters:


size of column
function duration time


INT (BIGINT) always will be smaller than CHAR(36) - as result less memory usage, more data in memory for index recreate operations (such as massive insert)

Increment will be faster any other form of random generator in 99% of cases

So in case of TAXNUMBER as primary key:


advantage - no any function for generate this type of key
disadvantage - most of them will take more memory than INT (BIGINT)


Add some visual examples:
make a proper test it very hard, but this is small example:
was created 3 tables, with only 1 column ID - primary key


UNSIGNED INT AUTOINCREMENT
BINARY(16)
VARCHAR(36)


was created stored procedure which insert 11M of records in each table, time results, very close:


11m41s - INT
12m40s - UUID() -> binary(16)
12m40s - UUID() -> varchar(36)


with time difference will need adjust server settings
but if we check size on disk (tables include only 1 column, PK)

-rw-r-----  1 _mysql  _mysql   1.1G 29 Nov 01:00 t__binary.ibd
-rw-r-----  1 _mysql  _mysql   268M 29 Nov 01:01 t__uint.ibd
-rw-r-----  1 _mysql  _mysql   1.6G 29 Nov 01:00 t__varchar.ibd


we can see the difference, and as bigger will be data, as much more will be difference