我有一张有1000万条记录的表格.那是考虑了很多记录吗？我应该担心搜索时间吗？如果不是,它会不断增长,那么什么被认为是一张大桌子？表大小因素在搜索时间中有多少,我可以做些什么来改善这些问题,最好在成为问题之前？
解决方法
“大”就像“聪明” – 这是相对的. 1000万行是一个很好的大小,但是表是否很大取决于多个因素：
>多少列及其数据类型是什么？
>有多少索引？
>表的实际大小是什么(例如,可以从sys.dm_db_partition_stats获得的页数* 8kb)？
>运行什么类型的查询？
>是存储在内存中的单个索引,或者大多数查询从集群索引扫描中获益(其中基本上整个表需要在内存中)？
>机器上有多少内存？
>你认为什么大？
搜索时间不一定是由大小本身驱动的,而是索引策略的有效性和您正在搜索的查询的类型.如果你有这样的事情：
WHERE description LIKE '%foo%'
那么正常的索引不会帮助你,你应该开始担心.您可以考虑全文搜索这样的案例.
具有单个INT列(例如Numbers表)的表中的1000万行是没有的.具有长描述,XML,地理数据,图像等的1000万行产品是另一回事.
有一个原因,sql Server的最大容量规范不会记录表中行数的上限.
