SQL Server : 테이블의 최대 행 수

SQL Server : 테이블의 최대 행 수

---

데이터베이스 테이블 (SQL Server 버전 8, 9 또는 10) 중 하나에 많은 데이터를 저장하는 소프트웨어를 개발합니다. 하루에 약 100,000 개의 레코드가 해당 테이블에 삽입된다고 가정 해 보겠습니다. 이것은 연간 약 3,600 만 개의 레코드입니다. 성능이 저하 될까봐 걱정이되어 매일 새 테이블 (이름에 현재 날짜가있는 테이블)을 만들어 테이블 당 레코드 수를 줄이기로 결정했습니다.

그게 좋은 생각인지 말씀해 주시겠습니까? SQL Server 테이블에 대한 레코드 제한이 있습니까? 또는 성능이 크게 저하되기 전에 테이블에 저장할 수있는 레코드 수 (다소)를 알고 있습니까?

---

이에 대한 일반적인 대답을 제공하기는 어렵습니다. 실제로 여러 요인에 따라 다릅니다.

• 행의 크기
• 저장하는 데이터의 종류 (문자열, 얼룩, 숫자)
• 데이터로 무엇을합니까 (아카이브로 보관하고 정기적으로 쿼리)
• 테이블에 인덱스가 있습니까?
• 당신의 서버 사양은 무엇입니까

기타

여기의 다른 곳에서 대답했듯이 하루에 100,000, 따라서 테이블 당 과잉입니다. 매월 또는 매주 아마도 분기별로 제안 할 것입니다. 테이블이 많을수록 더 큰 유지 관리 / 쿼리 악몽이 될 것입니다.

---

다음은 SQL Server 2008 R2 의 최대 용량 사양 중 일부입니다.

• 데이터베이스 크기 : 524,272TB
• SQL Server 인스턴스 당 데이터베이스 : 32,767
• 데이터베이스 당 파일 그룹 : 32,767
• 데이터베이스 당 파일 : 32,767
• 파일 크기 (데이터) : 16TB
• 파일 크기 (로그) : 2TB
• 테이블 당 행 : 사용 가능한 저장 용량에 의해 제한됨
• 데이터베이스 당 테이블 : 데이터베이스 의 개체 수에 의해 제한됨

---

SQL Server 2008 R2에는 60 억 개가 넘는 행이있는 3 열 테이블이 있습니다.

매일 쿼리하여 고객을위한 분 단위 시스템 분석 차트를 만듭니다. 데이터베이스 성능 저하를 발견하지 못했습니다 (매일 ~ 1GB가 증가한다는 사실 때문에 백업 관리가 원하는 것보다 약간 더 복잡해집니다).

2016 년 7 월 업데이트

백업이 2 년이 넘은 레코드를 잘라내기로 결정할 수있을만큼 충분히 커지기 전에 최대 245 억 행 으로 만들었습니다 (고가의 테이프를 포함하여 여러 백업에 저장되는 최대 700GB). 이 결정에서 성과가 중요한 동기가 아니었다는 점은 주목할 가치가 있습니다 (즉, 여전히 훌륭하게 작동하고 있음).

SQL Server에서 200 억 개의 행을 삭제하려는 경우이 기사를 적극 권장 합니다 . 링크가 죽는 경우 관련 코드 (전체 설명은 기사 참조) :

ALTER DATABASE DeleteRecord SET RECOVERY SIMPLE;
GO

BEGIN TRY
    BEGIN TRANSACTION
        -- Bulk logged 
        SELECT  *
        INTO    dbo.bigtable_intermediate
        FROM    dbo.bigtable
        WHERE   Id % 2 = 0;

        -- minimal logged because DDL-Operation 
        TRUNCATE TABLE dbo.bigtable;  

        -- Bulk logged because target table is exclusivly locked! 
        SET IDENTITY_INSERT dbo.bigTable ON;
        INSERT INTO dbo.bigtable WITH (TABLOCK) (Id, c1, c2, c3)
        SELECT Id, c1, c2, c3 FROM dbo.bigtable_intermediate ORDER BY Id;
        SET IDENTITY_INSERT dbo.bigtable OFF;
    COMMIT
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0
        ROLLBACK
END CATCH

ALTER DATABASE DeleteRecord SET RECOVERY FULL;
GO

2016 년 11 월 업데이트

If you plan on storing this much data in a single table: don't. I highly recommend you consider table partitioning (either manually or with the built-in features if you're running Enterprise edition). This makes dropping old data as easy as truncating a table once a (week/month/etc.). If you don't have Enterprise (which we don't), you can simply write a script which runs once a month, drops tables older than 2 years, creates next month's table, and regenerates a dynamic view that joins all of the partition tables together for easy querying. Obviously "once a month" and "older than 2 years" should be defined by you based on what makes sense for your use-case. Deleting directly from a table with tens of billions of rows of data will a) take a HUGE amount of time and b) fill up the transaction log hundreds or thousands of times over.

---

I do not know of a row limit, but I know tables with more than 170 million rows. You may speed it up using partitioned tables (2005+) or views that connect multiple tables.

---

I don't know MSSQL specifically, but 36 million rows is not large to an enterprise database - working with mainframe databases, 100,000 rows sounds like a configuration table to me :-).

While I'm not a big fan of some of Microsoft's software, this isn't Access we're talking about here: I assume they can handle pretty substantial database sizes with their enterprise DBMS.

I suspect days may have been too fine a resolution to divide it up, if indeed it needs dividing at all.

---

We have tables in SQL Server 2005 and 2008 with over 1 Billion rows in it (30 million added daily). I can't imagine going down the rats nest of splitting that out into a new table each day.

Much cheaper to add the appropriate disk space (which you need anyway) and RAM.

---

It depends, but I would say it is better to keep everything in one table for that sake of simplicity.

100,000 rows a day is not really that much of an enormous amount. (Depending on your server hardware). I have personally seen MSSQL handle up to 100M rows in a single table without any problems. As long as your keep your indexes in order it should be all good. The key is to have heaps of memory so that indexes don't have to be swapped out to disk.

On the other hand, it depends on how you are using the data, if you need to make lots of query's, and its unlikely data will be needed that spans multiple days (so you won't need to join the tables) it will be faster to separate out it out into multiple tables. This is often used in applications such as industrial process control where you might be reading the value on say 50,000 instruments every 10 seconds. In this case speed is extremely important, but simplicity is not.

---

We overflowed an integer primary key once (which is ~2.4 billion rows) on a table. If there's a row limit, you're not likely to ever hit it at a mere 36 million rows per year.

---

You can populate the table until you have enough disk space. For better performance you can try migration to SQL Server 2005 and then partition the table and put parts on different disks(if you have RAID configuration that could really help you). Partitioning is possible only in enterprise version of SQL Server 2005. You can look partitioning example at this link: http://technet.microsoft.com/en-us/magazine/cc162478.aspx

Also you can try to create views for most used data portion, that is also one of the solutions.

Hope this helped...

---

Largest table I've encountered on SQL Server 8 on Windows2003 was 799 million with 5 columns. But whether or not it's good will is to be measured against the SLA and usage case - e.g. load 50-100,000,000 records and see if it still works.

---

SELECT Top 1 sysobjects.[name], max(sysindexes.[rows]) AS TableRows, 
  CAST( 
    CASE max(sysindexes.[rows]) 
      WHEN 0 THEN -0 
      ELSE LOG10(max(sysindexes.[rows])) 
    END 
    AS NUMERIC(5,2)) 
  AS L10_TableRows 
FROM sysindexes INNER JOIN sysobjects ON sysindexes.[id] = sysobjects.[id] 
WHERE sysobjects.xtype = 'U' 
GROUP BY sysobjects.[name] 
ORDER BY max(rows) DESC

---

테이블을 매월 분할하십시오. Oracle 또는 MSSQL과 같이 일일 유입량이 많은 테이블을 처리하는 가장 좋은 방법입니다.

참고 URL : https://stackoverflow.com/questions/759244/sql-server-the-maximum-number-of-rows-in-table