觅高手
找高手
好久没来了，来了就有好问题
现在公司业务扩大每天有1千万数据写入单个表中，序列会溢出，而且有400多个人都在陆续往各个表里写入数据，有20多个人要调取这些数据，各种统计修改，在多表联合查询的时候，数据库频繁锁死，不能工作。
现在用的数据库是ＳＱＬＳＥＲＶＥＲ2000 优化查询只用了一些索引什么的，但是所有连这个库的软件，都有慢的迹象
请大神大牛们给些指导性的意见或是解决方案。
------解决方案--------------------
并发的量在2000下还算是比较大了。
如果有可能 还是建议使用SQL 2008以上的数据库 对并发的处理要高很多。
另外 如果是32位操作系统的话 内存不能完全使用 即使开启了AWE也就那样。
所以还是建议使用64位的操作系统
------解决方案--------------------
序列会溢出——改BIGINT。或者考虑分表，比如在前端做轮询之类的操作，举个例子，假设userid是有地域性的，那么你就每个省建一套表（记住是一套不是一个），前端根据userid，然后就只针对userid所在的省份操作相关的那套表。
------解决方案--------------------
如果使用2008，考虑用分区，但是轮询的思想应该也要用上
------解决方案--------------------
1000W以上数据需要分区表 也需要归档
你从2000的服务器到2008上面去的话 数据迁移也要注意 不是一句话能说清楚的
------解决方案--------------------
整理一下lz的需求
单表，最高420并发，日1千万数据增量。
1、先解决写入的问题，如果可以按照一定逻辑分表最好，如果不能，考虑使用分区表
2、查询问题，建议读写分离，如果数据要求可以有一定滞后，比如30分钟前的数据统计。lz可以使用另外的服务器存储，并分发查询。可能使用的数据库技术参考 复制
注：如果前台是web应用，是否可以考虑使用多服务器分担负载？
核心思想就是 资源分离，各取所需！
------解决方案--------------------
每天1KW数据量不小了，单靠升级数据库或者服务器硬件是不够的。
常规做法是分库分表，NoSQL也是一种选择。
------解决方案--------------------
sql2005是个较大的阶段性改进
int不够改bigint
把不是交易必须的记录，移到历史表，甚至移到另外一个服务器——查询的用户只访问它好了
另外为查询提供一些中间汇总表，也可减轻查询压力
如果交易表还大，则改为 分区表（应用、sql无须任何改动）
好久没来了，来了就有好问题
现在公司业务扩大每天有1千万数据写入单个表中，序列会溢出，而且有400多个人都在陆续往各个表里写入数据，有20多个人要调取这些数据，各种统计修改，在多表联合查询的时候，数据库频繁锁死，不能工作。
现在用的数据库是ＳＱＬＳＥＲＶＥＲ2000 优化查询只用了一些索引什么的，但是所有连这个库的软件，都有慢的迹象
请大神大牛们给些指导性的意见或是解决方案。
------解决方案--------------------
并发的量在2000下还算是比较大了。
如果有可能 还是建议使用SQL 2008以上的数据库 对并发的处理要高很多。
另外 如果是32位操作系统的话 内存不能完全使用 即使开启了AWE也就那样。
所以还是建议使用64位的操作系统
------解决方案--------------------
序列会溢出——改BIGINT。或者考虑分表，比如在前端做轮询之类的操作，举个例子，假设userid是有地域性的，那么你就每个省建一套表（记住是一套不是一个），前端根据userid，然后就只针对userid所在的省份操作相关的那套表。
------解决方案--------------------
如果使用2008，考虑用分区，但是轮询的思想应该也要用上
------解决方案--------------------
1000W以上数据需要分区表 也需要归档
你从2000的服务器到2008上面去的话 数据迁移也要注意 不是一句话能说清楚的
------解决方案--------------------
整理一下lz的需求
单表，最高420并发，日1千万数据增量。
1、先解决写入的问题，如果可以按照一定逻辑分表最好，如果不能，考虑使用分区表
2、查询问题，建议读写分离，如果数据要求可以有一定滞后，比如30分钟前的数据统计。lz可以使用另外的服务器存储，并分发查询。可能使用的数据库技术参考 复制
注：如果前台是web应用，是否可以考虑使用多服务器分担负载？
核心思想就是 资源分离，各取所需！
------解决方案--------------------
每天1KW数据量不小了，单靠升级数据库或者服务器硬件是不够的。
常规做法是分库分表，NoSQL也是一种选择。
------解决方案--------------------
sql2005是个较大的阶段性改进
int不够改bigint
把不是交易必须的记录，移到历史表，甚至移到另外一个服务器——查询的用户只访问它好了
另外为查询提供一些中间汇总表，也可减轻查询压力
如果交易表还大，则改为 分区表（应用、sql无须任何改动）