UUID in mysql database I have a problem, I have two servers  where I have to save my data. For persistent data I run mySql inno DB. I have a lot of entries, so I need fast (CRUD operations).

For indexing I was thinking to use UUID() or UUID_SHORT(). Auto increment is out of the options, because the data will be replicated. 

The problems are that, at UUID() the DB will become very slow. At UUID_SHORT() the problem arise that it's not true unique, if I won't often restart mySql server. According to documentation, mySql DOC I can create only 16000000 entries. 

What should I use for indexing?  

Any help would be appreciate.
The docs on UUID_SHORT() are a little bit short on actual detail, and I suspect you are not seeing the complete story on how this function works.

As long as you do not have more than one server in the system with the same bits in the low-order byte of the @@server_id, and you don't set the system clock back in time and then restart MySQL server, and don't generate more than 16.7 million calls to UUID_SHORT() per second for every second of every minute that the server is running, then the values will be unique.

--- 64 bits of bigint unsigned comprising the initial value ----
6666555555555544444444443333333333222222222211111111110000000000
3210987654321098765432109876543210987654321098765432109876543210
|------||------------------------------||----------------------|
@@server_id     unix_timestamp of          monotonic counter
low-order      server startup time         starts at 0, increments
byte                                       up +1 with each call,
&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt;&lt; overflows this way 
                                           when it rolls over
                                           past 24 bits


The counter is initialized as shown above with each server start, and generates a value incremented by 1 each time UUID_SHORT() is called.  It does not increment the unix_timestamp portion of the value for each tick of the wall clock -- it overflows the counter up into that portion of the value, effectively conserving this resource (of usable values) and avoiding collisions caused by a normal server restart.

Thus, if you don't generate more than 2^24 (16,777,216) calls per second every second, then the next time the server starts, it will initialize at a much higher value (relatively speaking) than where it left off.  Setting the system clock back in time would also be unlikely to be problematic unless you set it back close enough to the time of the prior server restart to cause overlapping values.