在大型互聯網應用中，隨着用戶數的增加，為了提高應用的性能，我們經常需要對數據庫進行分庫分表操作。在單表時代，我們可以完全依賴於數據庫的自增 ID來唯一標識一個用戶或數據對象。但是當我們對數據庫進行了分庫分表后，就不能依賴於每個表的自增ID來全局唯一標識這些數據了。因此，我們需要提供一 個全局唯一的ID號生成策略來支持分庫分表的環境。下面來介紹兩種非常優秀的解決方案：
1. 數據庫自增ID——來自Flicker的解決方案
因為MySQL本身支持auto_increment操作，很自然地，我們會想到借助這個特性來實現這個功能。Flicker在解決全局ID生成方 案里就采用了MySQL自增長ID的機制（auto_increment + replace into + MyISAM）。一個生成64位ID方案具體就是這樣的：
先創建單獨的數據庫(eg:ticket)，然后創建一個表：
CREATE TABLE Tickets64 ( id bigint(20) unsigned NOT NULL auto_increment, stub char(1) NOT NULL default '', PRIMARY KEY (id), UNIQUE KEY stub (stub) ) ENGINE=MyISAM 當我們插入記錄后，執行SELECT * from Tickets64，查詢結果就是這樣的：
+-------------------+------+ | id | stub | +-------------------+------+ | 72157623227190423 | a | +-------------------+------+ 在我們的應用端需要做下面這兩個操作，在一個事務會話里提交：
REPLACE INTO Tickets64 (stub) VALUES ('a'); SELECT LAST_INSERT_ID(); 這樣我們就能拿到不斷增長且不重復的ID了。
到上面為止，我們只是在單台數據庫上生成ID，從高可用角度考慮，接下來就要解決單點故障問題：Flicker啟用了兩台數據庫服務器來生成ID，通過區分auto_increment的起始值和步長來生成奇偶數的ID。
TicketServer1:
auto-increment-increment = 2 auto-increment-offset = 1 TicketServer2: auto-increment-increment = 2 auto-increment-offset = 2 最后，在客戶端只需要通過輪詢方式取ID就可以了。
- 優點：充分借助數據庫的自增ID機制，提供高可靠性，生成的ID有序。
- 缺點：占用兩個獨立的MySQL實例，有些浪費資源，成本較高。
參考：http://code.flickr.net/2010/02/08/ticket-servers-distributed-unique-primary-keys-on-the-cheap/
2. 獨立的應用程序——來自Twitter的解決方案
Twitter在把存儲系統從MySQL遷移到Cassandra的過程中由於Cassandra沒有順序ID生成機制，於是自己開發了一套全局唯一ID生成服務：Snowflake。GitHub地址：https://github.com/twitter/snowflake。根據twitter的業務需求，snowflake系統生成64位的ID。由3部分組成：
41位的時間序列（精確到毫秒，41位的長度可以使用69年）
10位的機器標識（10位的長度最多支持部署1024個節點）
12位的計數順序號（12位的計數順序號支持每個節點每毫秒產生4096個ID序號）
最高位是符號位，始終為0。
- 優點：高性能，低延遲；獨立的應用；按時間有序。
- 缺點：需要獨立的開發和部署。
注：last_insert_id()的值是由MySQL server來維護的，而且是為每條連接維護獨立的值，也即，某條連接調用last_insert_id()獲取到的值是這條連接最近一次insert操作執行后的自增值，該值不會被其它連接的sql語句所影響。這個行為保證了不同的連接能正確地獲取到它最近一次insert sql執行所插入的行的自增值，也就是說，last_insert_id()的值不需要通過加鎖或事務機制來保證其在多連接場景下的正確性