首页(百科问答网) » 电脑/数码/通讯/互联网 » 编程/开发 » 正文

MySQL如何直接实现sub-table-level auto inc

原先有一堆同结构的小表，都有auto inc 的id 列。
现在要把所有数据放入一个大表里去，也就是把原先小表的结构上再加一列：tableId
然后就把所有小表的数据倒进来。

现在的问题在于：在这个大表里针对某个tableId insert一行，这个id如果仍是auto inc，那它对于这个tableId就是不连续的。
有没办法这个id基于每个tableId而自增长，而不是table-level的？

主要考虑的是性能。
谢谢。

答案或建议：

tableid + id (auto inc)作为主键，就是你要的效果； id (auto inc) + tableid做主键是不行的。
下边是我以tableid + id 做主键，连续插入的结果

tid id name
1 1 A0
1 2 A1
2 1 B1
2 2 B0
1 3 a3

--------

前几天知道insert时可以手动设定id 值时，就把注意力放到了id自增上。--因为倒原数据不是问题了，问题在于以后新表上的增加数据。

当时不知道auto inc可以依prefix而自增，所以设想的办法也就是在调一份数据时、在服务器端查得相应的max(id)...我们有10来个表需要这么做，也许会维护一个lookup table；服务器内存里只用维护当前活动数据的相关max(id)...
倒是英雄所见略同。

现在一些表的单表数据加起来已经超过2G行了...
原先表里加了很多索引，在初期测试里，加不加这些索引，对数据合成的速度没有明显影响----这以后肯定会大有影响的。
如果brainId INT 4 + id BIGINT 8, 共12 bytes，primary key上会建索引，应该不会全表扫描吧？
不过，我还没来得及搞个大库来做测试呢。

数据库服务我们是买的，服务方大概是提出了分散式的数据结构，也许是象amazon rds那样的。

不过，细节我不知道。大概是服务方告诉我们类似量级的只要掏钱就没什么问题。
我现在是从个人版出发向网络端前进，另一端不自己操心。
对我是个不错的机会，我以前只体验过M级的数据库，（企业内部的表单之类，多不起来。）现在有可能到T级上，而且一开始就拖着历史包袱，hehe......我喜欢。

你提议的id分区，的确很聪明。这就意味着：physical id = logic id + brainId * 10^8; 程序上转换简单明快。我以前就没想到。
后来我想了很久，MySQL里之所以把合并主键的前项称为prefix，它肯定是用了移位算法来替代乘法：pkey = id | brainId < 8；移位是一个时钟周期，而乘法得3个吧？

至于myISAM的table-lock，我现在想，可以用partition来提高性能。——这是我现在望文生义的想法。
若这样，正是3L说法的倒着来：逻辑上的一个大表拆成互不干涉的多个物理子表。
我没负责过数据库，这些都是些现在的想法。到底效果如何，这次有机会亲身体验一下一了。

DBA这活，还是挺有意思的。

链接地址：http://www.baikewenda.com/h/1011/a36742.html

MySQL如何直接实现sub-table-level auto inc

答案或建议：

推荐内容