现在数据库里有十几张表，每张表的数据过几千万。
为了提高查询的效率，现在想把这十几张表，按表里的数据类型再分成子表，分下来大概有6000多张子表，因为查询的时候主要是按这个数据类型为条件再外加其他条件进行查询的，这样分下来的话每张表里只存这个类型的数据，数据量会缩小，查询效率应该会提高，但不知道这么多表会有其他什么影响？
还有就是除了加索引外还有其他什么好的方案能解决这几千万甚至上亿数据查询效率问题？
而且这十几张表里的数据是在每天更新的，加索引可能会影响更新速度。现在的更新方式是直接把原来的全部删掉，然后insert，由于数据量比较大，删除数据时没有用delete（比较慢），而是直接drop掉表，然后重建，这样有没有什么问题隐患？
------解决方案--------------------
为什么 不做成 分区表呢？ 按 这个类型 list分区
------解决方案--------------------
但不知道这么多表会有其他什么影响？
--> 虽然分小表的数据量会缩小,但始终还是会增加上来的,到时如何处理.
且前端程序需大量使用动态SQL查询,修改工作量较大.
接drop掉表，然后重建，这样有没有什么问题隐患？
--> 从drop表到重建,导入大数据量完成,需一定的时间,期间查询会报错: 找不到表xxx.
且大数据量导入,会使日志文件暴涨.
可以考虑分区表方案,
或把历史数据(例如N年前的)归档到历史数据库中,有需求才去查询.
------解决方案--------------------
1.这么多表对系统应该没什么影响，但是这么多表加重了管理这些表的负担，相当于你使用管理的复杂性，来换取了性能，这种思路是对的。
我建议如果可以的话，把原来的表按照你说的数据类型，改为分区表，但你说拆分后有6000多个表，SQL server 2008r2的分区表只能支持1000个分区，那么可能还得把有些数据类型放到一个分区表中，另外，导入数据时，可能的一个一个类型倒入，比如类型1导入到表1，然后把这个表1加入到分区表中，这样做的好处是非常快。
也就是说采用了分区表，其实管理的复杂性也有上升，但性能和方便程度，都有大幅提高。
不过有个问题是，好像2008r2分区表，只支持range分区，好像不支持list分区。所以，你这个问题，要修改为分区表，也有一定的困难。
3.你说由于delete太慢，直接通过drop来删除数据，然后重建，其实直接用truncate删除数据，应该就很快的，不用一定要drop后再重建的。
本来比如有1000条数据，那么需要删除其中的500条，然后再加载新的500，最后还是1000条，既然你可以drop表，说明你现在导入数据时，是全量导入，就是把以前的数据，和新的数据，一起导入，这样就避免了delete太慢的问题，确实是一个办法，因为（drop+全量导入+重建表）时间 < (delete+新数据导入)时间。
你说你的更新方式是每天都是更新的，因为看你说的意思，应该是批量更新的，不是每秒都有更新的，是佛可以考虑在更新的时候把索引禁用，然后在导入完成后重建索引，就可以了，另外，不用drop表，直接truncate表就可以了。
2.要解决这种大数据量的查询问题，还是得建索引，索引是提高查询速度的关键，要想快，就得建索引哈。
------解决方案--------------------
做分区表吧，不用INSERT 之类的 ，Switch就是 元数据级别的，不涉及数据的移动 性能好很多 ，而且简化你的维护。
大数据如果只是查询少量的数据还是要靠索引，分区表的索引会更快。
------解决方案--------------------
删除表再建表，怎么会比更新数据快？
几千万条也不多啊，查询速度快慢与索引和查询语句本身的关系更大一些！
------解决方案--------------------
1.每个几十分钟，就要导入一批呀，我在原来公司曾经尝试过，对一个1.5亿条的表，大概30个字段把，重建索引大概10分钟左右吧，所以如果你的数据量上亿了，确实重建索引的开销会比较大，对系统会有影响。
2，你可以根据你的需要设置分区时间，随着时间的变化，确实像你所说的，需要改变分区函数的间隔值。
另外，你说每个几十分钟，导入一批数据，是导入到某一个表，还是可能会导入到所有的表中呢
------解决方案--------------------
分区表和，把一个表分成很多子表相比，
分区表是逻辑上是一个表，而分成很多的子表，像你说的有6000个表，在查询效率、管理的方便、历史数据的迁移，可用性等方面，都更有效率。
------解决方案--------------------
啥系统有这么大负荷，几千万的数据量就伤筋动骨？
正确设计一下，可能服务器日子过得比较悠闲
是否要索引，索引多或少，是综合需求确定的。。而不是用片面理论去作标准
------解决方案--------------------
哦，不好意思哈，我没有说清楚，是分区表总体效率更高哈。
------解决方案--------------------
其实可以从以下几方面做：
1、多建几个文件组，不同的文件放在不同的文件组中，当然如果再用到表分区效果更好。
2、可以增加磁盘，提高磁盘的读写速度。
3、表结构的设计也非常重要。索引及主键建得好不好会影响到删除及更新。如果更新尽量不要是索引列，删除时可以根据索引的条件进行删除。
------解决方案--------------------
而且这十几张表里的数据是在每天更新的，加索引可能会影响更新速度。现在的更新方式是直接把原来的全部删掉，然后insert，由于数据量比较大，删除数据时没有用delete（比较慢），而是直接drop掉表，然后重建，这样有没有什么问题隐患？
这句已经满足你用truncate了，先truncate再drop，然后重建或者不用重建，这样速度快很多，空间消耗也少，直接drop大表的话ldf增长很大。对于你其他问题，预期这样分，不如做个分区。多表关联可能会导致使用动态sql来拼接，增大编程工作量，多表关联也会导致优化器的候选方案非常多，好像是阶乘级别。12张表关联以前看过资料要评估过亿中方案，可想而知消耗资源特别是CPU会有多高