在分庫分表環境中，由於表中資料同時存在不同資料庫中，主鍵值平時使用的自增長將無用武之地，某個分割槽資料庫自生成的id無法保證全域性唯一。因此需要單獨設計全域性主鍵，下面是幾種生成唯一id的方式方法：
1)uuid
uuid標準形式包含32個16進製制數字，分為5段，形式為8-4-4-4-12的36個字元，例如：550e8400-e29b-41d4-a716-446655440000
uuid是主鍵是最簡單的方案，本地生成，效能高，沒有網路耗時。
但缺點也很明顯，由於uuid非常長，會占用大量的儲存空間；
另外，作為主鍵建立索引和基於索引進行查詢時都會存在效能問題，在innodb下，uuid的無序性會引起資料位置頻繁變動，導致分頁。
2)結合資料庫維護主鍵id表
在資料庫中建立 sequence 表：create table `sequence` (
`id` bigint(20) unsigned not null auto_increment,
`stub` char(1) not null default '',
primary key (`id`),
unique key `stub` (`stub`)
) engine=myisam;
使用 myisam 儲存引擎而不是 innodb，以獲取更高的效能。myisam使用的是表級別的鎖，對錶的讀寫是序列的，所以不用擔心在併發時兩次讀取同乙個id值。
此方案較為簡單，但缺點也明顯：存在單點問題，強依賴db，當db異常時，整個系統都不可用。配置主從可以增加可用性，但當主庫掛了，主從切換時，資料一致性在特殊情況下難以保證。另外效能瓶頸限制在單台mysql的讀寫效能。
3)類snowflake方案
這種方案大致來說是一種以劃分命名空間(uuid也算，由於比較常見，所以單獨分析)來生成id的一種演算法，這種方案把64-bit分別劃分成多段，分開來標示機器、時間等
優點：毫秒數在高位，自增序列在低位，整個id都是趨勢遞增的。
不依賴資料庫等第三方系統，以服務的方式部署，穩定性更高，生成id的效能也是非常高的。
可以根據自身業務特性分配bit位，非常靈活。
缺點：強依賴機器時鐘，如果機器上時鐘回撥，會導致發號重複或者服務會處於不可用狀態。
4)採用redis 自增長id
redis，操作記憶體，其效能相當的優越
flask sqlalchemy分表解決方案
flask sqlalchemy,sqlalchemy,分表，分庫 大型系統 海量資料肯定涉及到分庫分表這些提高效率的手段。由於sqlalchemy的orm思想是一張表對應乙個物件，那麼當我們有n張相同結構只是表名有區別的分表，sqlalchemy orm怎樣處理呢。比如有如下表 create ta...
mysql 分表聯合查詢 解決分表後聯合查詢
解決分表後聯合查詢 merge儲存引擎，也被認識為mrg myisam引擎，是乙個相同的可以被當作乙個來用的myisam表的集合。相同 意味著所有表同樣的列和索引資訊。你不能合併列被以不同順序列於其中的表，沒有恰好同樣列的表，或有不同順序索引的表。而且，任何或者所有的表可以用myisampack來壓...
mysql分表準則 Mysql分表準則
mysql分表準則 在大量使用mysql時，資料量大 高訪問時，為了提高效能需要分表處理，簡介下mysql分表的標準，後續會繼續補充 環境 業務型別 oltp 硬體 cpu 8cpu 2.4ghz mem 48g 磁碟 raid5 6 sas 什麼樣的表需要拆分 根據表的體積 表的行數 訪問特點來衡...