最近有一个产品尝试采用 UUID 代替默认的 int 主键。
由于没有在大规模的生产环境中这样用过,虽然搜索了关于 MySQL UUID 主键的优劣势文章,但毕竟案例还是太少,很多还停留在性能测试阶段。
论坛中是否有朋友在生产环境中采用过 ActiveRecord + MySQL UUID 主键的方案,有没有什么特别的坑?
最近有一个产品尝试采用 UUID 代替默认的 int 主键。
由于没有在大规模的生产环境中这样用过,虽然搜索了关于 MySQL UUID 主键的优劣势文章,但毕竟案例还是太少,很多还停留在性能测试阶段。
论坛中是否有朋友在生产环境中采用过 ActiveRecord + MySQL UUID 主键的方案,有没有什么特别的坑?
5 回答3.3k 阅读✓ 已解决
3 回答3.6k 阅读✓ 已解决
2 回答2.8k 阅读✓ 已解决
5 回答1.4k 阅读
2 回答1.8k 阅读
3 回答2k 阅读
1 回答3.6k 阅读
看网上资料,主键的字段类型设置引起不同的性能变化
postgresql的uuid比text省空间
http://simononsoftware.com/how-to-store-uuids-in-postgresql/
SO上关于mysql的两篇文章
http://stackoverflow.com/questions/412341/how-should-i-store-guid-in-mysql-tables
http://stackoverflow.com/questions/2365132/uuid-performance-in-mysql/2365176
UUID的优势就是天然适应高并发的环境下使用。如果id顺序递增,每创建一条记录都需要对表加一次锁,这在高并发环境下是很大的开销,有时候甚至是不能容忍的。
你只在单机上进行测试会导致插入性能随数据量指数级减慢。而UUID可以无痛支持对表进行水平划分,将数据分布存储在多台不同的机器上。只要机器可以无限扩展,插入性能就能够得到保证。