在SQL Server中的非常大的表格。
在SQL Server中的非常大的表格。
我们的SQL Server 2005 64位标准版上有一个非常大的表格（>7700万条记录且不断增长），我们遇到了一些性能问题。每天可能会添加上百万条记录。
有没有人知道SQL Server标准版可以处理的记录数量是否有限制？我们是否应该考虑升级到企业版，还是有一些技巧可以使用？
额外信息：
所讨论的表格相当扁平（14个列），有一个包含6个字段的聚集索引，以及两个单个字段的其他索引。
我们添加了一个第四个索引，使用了在一个有问题的查询中的3个字段，并没有看到预估性能上的任何差异（该查询是必须在非工作时间运行的过程的一部分，所以我们还没有度量结果）。这些字段是聚集索引的一部分。
非常大的SQL Server表格的问题主要出现在以下几个方面：索引过多、填充因子设置不当、统计信息缺失、索引碎片化、查询执行计划不合理以及统计信息不准确。针对这些问题，可以采取以下解决方法：
1. 减少聚集索引的数量，最好只保留1或2个字段作为聚集索引。选择合适的字段，如IDENTITY（INT）字段、日期字段或其他能够按照数据添加方式进行自然排序的字段。将被移除的字段放入非聚集索引中，以保证查询效率。
2. 检查索引的填充因子。填充因子的数值越大（100），数据页和索引页的填充率越高。根据插入记录的数量和频率，调整非聚集索引的填充因子，以便为新的或重组的记录留出空间。一般来说，对于高写入量的情况，填充因子设置为60-70；对于中等写入量，设置为70-90；对于高读取量和低写入量，设置为90-100。
3. 确保表格上存在统计信息。可以使用"sp_createstats 'indexonly'"命令在数据库中创建统计信息，该命令只会为引擎已经积累了需要统计信息的索引创建统计。不要忘记添加'indexonly'属性，否则将为每个字段都创建统计信息。
4. 使用DBCC SHOWCONTIG命令检查表格和索引的碎片情况，了解哪些索引碎片化程度最高。根据这些信息，调整填充因子的设置，以适应索引的变化和变化速度。
5. 设置定时任务，在线或离线上对索引进行碎片整理。但是要注意，在表格较大的情况下，不要在非维护时间进行DBCC DBREINDEX操作，因为它会导致应用程序中断，特别是对于聚集索引来说。需要进行充分的测试和验证。
6. 使用执行计划来查看存在的扫描和瓶颈，并调整索引，然后对存储过程进行改写，以消除这些热点。如果在执行计划中看到红色对象，表示该字段缺乏统计信息，这是不好的。这一步骤更多的是"艺术而非科学"。
7. 在非高峰时段，运行UPDATE STATISTICS WITH FULLSCAN命令，尽可能地为查询引擎提供有关数据分布的更多信息。否则，在工作日的夜间或根据观察需要更频繁地运行标准的UPDATE STATISTICS（使用标准10%扫描）命令，以确保引擎对数据分布有更多的了解，以便高效地检索数据。
不需要升级到企业版，尽管我确实为了分区而升级到企业版。但是，我尤其是为了拥有更好的多线程搜索和在线碎片整理以及维护性能而进行了升级。在企业版中，处理非常大的数据库表格时，性能更好且更友好。标准版在处理在线数据库的DBCC INDEXDEFRAG方面表现不佳。
非常大的SQL Server表格可能会导致性能下降和查询速度变慢。出现这个问题的原因可能是索引不正确或缺失，导致查询时需要进行全表扫描。为了解决这个问题，我们可以考虑以下几个方法：
1. 索引优化：通过在经常进行查询的列上创建索引，可以大大提高查询性能。可以使用Management Studio中的执行计划生成器来查看执行计划，确保查询使用了索引搜索或聚集索引搜索，而不是表扫描。如果发现有表扫描的情况，应该考虑在查询的列上创建索引来优化性能。
CREATE INDEX IX_ColumnName ON TableName (ColumnName);
2. 分区表：如果表格非常大，可以考虑将其分割成多个分区。分区表可以提高查询性能，减少锁定冲突，并简化维护过程。可以根据业务需求和查询模式来确定分区策略。
CREATE PARTITION FUNCTION PartitionFunc (int)
AS RANGE LEFT FOR VALUES (1, 100, 1000);
CREATE PARTITION SCHEME PartitionScheme
AS PARTITION PartitionFunc
ALL TO ([Primary]);
3. 压缩表：如果表格非常大且数据存储空间有限，可以考虑压缩表格。SQL Server提供了数据压缩功能，可以减少存储空间，提高查询性能。
ALTER TABLE TableName REBUILD PARTITION = ALL WITH (DATA_COMPRESSION = ROW);
4. 数据归档：对于历史数据或不经常查询的数据，可以考虑将其归档到独立的表中。归档可以减小主表的大小，提高查询性能。
INSERT INTO ArchiveTable SELECT * FROM TableName WHERE Date < '2022-01-01';
DELETE FROM TableName WHERE Date < '2022-01-01';
总之，处理非常大的SQL Server表格的关键是优化索引、使用分区表、压缩表格和数据归档等方法。通过这些方法，可以提高查询性能，减少查询时间，并提升整体数据库的性能。不需要升级到Enterprise版来解决这个问题。
在SQL Server中，当存在一个有6个字段的聚集索引以及其他两个单字段的索引时，会出现以下问题：
- 聚集索引的字段会被包含在所有的非聚集索引中，作为从非聚集索引到实际数据页的最后一次查找方式。
- 如果有6个字段，每个字段占用8个字节，再乘以另外两个索引乘以7700万行，那么就会浪费大量的空间，这将转化为大量的I/O操作，从而降低性能。
- 对于聚集索引来说，它必须是唯一的、稳定的，并且尽可能地小（最好是一个INT或类似的类型）。
针对这个问题，可以采取以下解决方法：
- 尽量减小聚集索引的大小，以减少在非聚集索引中包含的字段数量。
- 如果可以，将聚集索引设置为唯一、稳定，并尽可能小（例如，使用一个INT类型）。
- 根据具体应用场景，根据需要选择将聚集索引设置为范围查询（例如BETWEEN）的字段，而不是一个没有语义意义的ID列。
这里提供了一篇关于Kim Tripp的“索引最佳实践”培训的博客文章链接：blogs.technet.com/josebda/archive/2009/03/17/…。其中一个主要观点是：“聚集索引键：唯一、窄、静态、递增”。
聚集索引的设计需要考虑唯一性、稳定性和尽可能小的大小，以减少空间浪费和I/O操作，从而提高性能。但具体的设计取决于应用程序的需求。