Download the PHP package vend/mysql-uuid without Composer
On this page you can find all versions of the php package vend/mysql-uuid. It is possible to download/install these versions without Composer. Possible dependencies are resolved automatically.
FAQ
Example:
In general, it is recommended to use always a project to download your libraries. In an application normally there is more than one library needed.
- Some hosting areas are not accessible by a terminal or SSH. Then it is not possible to use Composer.
- To use Composer is sometimes complicated. Especially for beginners.
- Composer needs much resources. Sometimes they are not available on a simple webspace.
- If you are using private repositories you don't need to share your credentials. You can set up everything on our site and then you provide a simple download link to your team member.
- Simplify your Composer build process. Use our own command line tool to download the vendor folder as binary. This makes your build process faster and you don't need to expose your credentials for private repositories.
Informations about the package mysql-uuid
MySQL UUIDs
Description
This is a small library for working with MySQL UUIDs in PHP. MySQL UUIDs are
128-bit values returned from the UUID() command in MySQL, and by default
are formatted as a hex-and-dash traditional UUID string, like this:
There are a couple of problems with using this sort of value directly:
- The string stores the most frequently changing timestamp field at the start (that is, it's little-endian); using this value directly will spread writes all across your tablespace and indexes, ruining any sort of locality. We want the last part of the string to contain the most frequently changing part of the UUID value.
- The string can't be directly used in a 128-bit column, such as
BINARY(16); storing the string directly would take about 37 bytes rather than 16, bloating indexes and row sizes.
MySQL UUIDs are generated according to "DCE 1.1: Remote Procedure Call" (Appendix A) CAE (Common Applications Environment) Specifications published by The Open Group in October 1997 (Document Number C706).
Why Do This?
Mainly for data clustering. We don't want a single buffer pool page to be under a lot of pressure for inserts (as would be the case with an auto_increment column), and we also don't want to randomly spread data across the entire index/table.
Installation
Install via composer. That's it.
Supported Formats
This library uses pack() and unpack() to munge MySQL UUID values into ones more suitable
for use as a database key. The supported formats are:
- Standard UUID strings, with dashes.
- Hex UUIDs, which are just like string UUIDs, but without the field separator dashes - perhaps useful for using with MySQL's
HEX()andUNHEX() - Binary UUIDs, which are 16 byte binary strings with just the underlying 128-bit UUID value, no formatting at all
Quick API Example
Field Reordering
String and Hex
Here's how the default MySQL-produced string UUID is built out of fields. We use this field structure for both the regular 'string' format, and the 'hex' format.
| Field | Type | Octet | Note |
|---|---|---|---|
| time_low | unsigned long | 0-3 | The low field of the timestamp. |
| time_mid | unsigned short | 4-5 | The middle field of the timestamp. |
| time_hi_and_version | unsigned short | 6-7 | The high field of the timestamp multiplexed with the version number. |
| clock_seq_hi_and_reserved | unsigned small | 8 | The high field of the clock sequence multiplexed with the variant. |
| clock_seq_low | unsigned small | 9 | The low field of the clock sequence. |
| node | character | 10-15 | The spatially unique node identifier. |
See what is meant by "ruins locality"? The fact time_low is the first field basically distributes your keys randomly over the possible ID space.
Reordered String
If you use the 'reordered' format, you'll instead get a UUID with this field format:
| Field | Type | Octet | Note |
|---|---|---|---|
| node_high | character | 0-3 | The high field of the spatially unique node identifier. |
| node_low | character | 4-5 | The low field of the spatially unique node identifier. |
| time_hi_and_version | unsigned short | 6-7 | The high field of the timestamp multiplexed with the version number. |
| clock_seq_hi_and_reserved | unsigned small | 8 | The high field of the clock sequence multiplexed with the variant. |
| clock_seq_low | unsigned small | 9 | The low field of the clock sequence. |
| time_midlow | unsigned 48-bit | 10-15 | The mid field (long) of the timestamp multiplexed with the low field (short) of the timestamp. |
Note that we leave the version and variant fields in the same place. This means if you have anything that gets information from the version and variant fields, or does something like parse the timestamp fields back out of the ID, then this format won't be backward compatible for you. Ideally, we'd set a different version or variant, but it's unclear which values are reserved (e.g. Microsoft has an assigned variant for their UUIDs), and this would still cause problems if we picked a variant already in use.
Binary
For binary UUIDs, we always reorder the field, and in a slightly more aggressive way than the reordered string format. There's no standard way to read the variant/version from a 16 byte binary value, and no field separators, so we rearrange the fields more aggressively (no need to keep the 4-2-2-2-6 byte format):
| Field | Type | Octet | Note |
|---|---|---|---|
| node | character | 0-5 | The spatially unique node identifier. |
| clock_seq_hi_and_reserved | unsigned small | 6 | The high field of the clock sequence multiplexed with the variant. |
| clock_seq_low | unsigned small | 7 | The low field of the clock sequence. |
| time_hi_and_version | unsigned short | 8-9 | The high field of the timestamp multiplexed with the version number. |
| time_mid | unsigned short | 10-11 | The middle field of the clock timestamp. |
| time_low | unsigned long | 12-15 | The low field of the timestamp. |
