SQL Server数据表数据量达到多大会影响查询和插入效率
项目中使用SQL Server存储一些采集数据，每分钟一条数据，每条数据大概有200多个字段。每年大概有50多万条数据。其中包括两个表，表A存储时间，以自增字段为主键。表B存数据，以ID字段作为主键，同时也是外键，指向表A的主键。
原来是考虑使用几年之后会导致数据表过大而影响效率，就像按照年份每年的数据存一个表。用户查询的时候就按照年份来查，然后把查询结果union之后返回给用户。但是现在遇到一个问题就是使用了坑爹的ado来访问数据库，ado的游标不支持union操作，所以想改回将所有数据都存在一张表里面。
请问一张数据表的数据达到多少条之后会影响插入和查询效率，以前听过说达到100万条数据之后查询和插入效率会大大降低，是这样吗？
------解决方案--------------------
SQL Server性能很大程度上取决于你的硬件，现在说100W根本不叫大数据量。
 
------解决方案--------------------
你都按年分了，那么 为什么还会union呢？

比如用户查今年，就去今年的表里查，查哪一年就去哪一年的表里查啊。
------解决方案--------------------
100w不叫大数据，建议取消外键，数据分区
------解决方案--------------------
建议
 1.用"union all"替代"union".

 2.ado的游标不支持union操作
   --> 应有解决方案.是否与CursorLocation属性有关.
       或写为存储过程,传入起始日期&结束日期,在存储过程中union all总可以吧.

 3.每年大概有50多万条数据
   --> 这样的数据量,应可不必按年存一个表.
------解决方案--------------------
你现在的数据大小完全不必考虑，除非出现了一行数据超过8060个字节，如果是超过，那么最好分表了，否则不用理会。
------解决方案--------------------
100多万虽不叫大数据，你有200多个列那就不太好说了。弱弱问一句这表是谁设计的。你这个一条数据库是不是就能占用一个数据页。如果从结构上设计的不好。那你的很多优化都是徒劳！
------解决方案--------------------

引用:

项目中使用SQL Server存储一些采集数据，每分钟一条数据，每条数据大概有200多个字段。每年大概有50多万条数据。其中包括两个表，表A存储时间，以自增字段为主键。表B存数据，以ID字段作为主键，同时也是外键，指向表A的主键。
原来是考虑使用几年之后会导致数据表过大而影响效率，就像按照年份每年的数据存一个表。用户查询的时候就按照年份来查，然后把查询结果union之后返回给用户。但是现在遇到一个问题就是使用了坑爹的ado来访问数据库，ado的游标不支持union操作，所以想改回将所有数据都存在一张表里面。
请问一张数据表的数据达到多少条之后会影响插入和查询效率，以前听过说达到100万条数据之后查询和插入效率会大大降低，是这样吗？

分区视图.....
------解决方案--------------------
100w的数据分个毛区啊。。。直接时间来个索引就可以了。
------解决方案--------------------
200个字段，什么东西能有200个属性啊？100多万条记录不多，但存储应该很大了吧，分区表长远考虑应该用。union 是T-Sql和ADO有什么关系？
一分钟插一条数据，开销不大，如果只查询几条数据，应该没有问题。如果有像你这种跨年的查询肯定会慢，没有好办法只能优化表结构或者优化索引。
------解决方案--------------------
1、请问一张数据表的数据达到多少条之后会影响插入和查询效率，以前听过说达到100万条数据之后查询和插入效率会大大降低，是这样吗？
没这个说法，100万查询如果你扫描的话那估计性能够呛的，如果不是扫描的话速度应该不会有什么指数级别的降低。插入如果是插到最后（有聚集索引且按顺序插入），那千万数据也不会慢，反正不影响上面的数据，但是如果你要反转再反转，那........
2、ado做这种事情一般都不是很擅长，去找找有没有其他方法把，而且你还用游标的话，如果没用好，性能会大打折扣。
3、100万数据的确没必要做分区或者分表，1个亿还差不多。
------解决方案--------------------
另外如果用到临时表，tempdb的配置、目标数据库数据文件的配置、增长比例等等都有可能影响效率。如果你觉得慢，应该全面排查，找出瓶颈
------解决方案--------------------
换个SSD，啥问题都解决了。哈哈