SQL Server: максимальное количество строк в таблице

Ответ 1

Трудно дать общий ответ на это. Это действительно зависит от количества факторов:

• какой размер вашей строки
• какие данные вы храните (строки, капли, цифры)
• что вы делаете с вашими данными (просто храните их в архиве, регулярно обращайтесь к ним)
• У вас есть индексы на вашем столе - сколько
• какие характеристики вашего сервера

и др.

Как было сказано в другом месте здесь, 100 000 в день и, следовательно, на таблицу слишком много - я предлагаю ежемесячно или еженедельно, возможно, даже ежеквартально. Чем больше таблиц у вас будет больше кошмара обслуживания/запроса, тем он станет.

Ответ 2

Вот некоторые из Максимальная емкость для SQL Server 2008 R2

• Размер базы данных: 524 272 терабайт
• Базы данных на экземпляр SQL Server: 32 767
• Файловые группы на каждую базу данных: 32 767
• Файлы для каждой базы данных: 32,767
• Размер файла (данных): 16 терабайт
• Размер файла (журнал): 2 терабайта
• Строки в таблице: ограничено доступной памятью
• Таблицы на базу данных: ограничено количеством объектов в базе данных

Ответ 3

У меня есть таблица с тремя столбцами с чуть более 6 миллиардами строк в SQL Server 2008 R2.

Мы запрашиваем его каждый день, чтобы создавать графические диаграммы системного анализа для наших клиентов. Я не заметил ни одной производительности производительности базы данных (хотя тот факт, что она растет ~ 1 Гбайт каждый день, делает управление резервными копиями более активным, чем хотелось бы).

Обновление Июль 2016

Мы сделали это до ~ 24,5 миллиардов строк, пока резервные копии не стали достаточно большими, чтобы мы могли урезать записи старше двух лет (~ 700 ГБ, хранящиеся в нескольких резервных копиях, в том числе на дорогих лентах). Стоит отметить, что производительность не была существенным стимулом в этом решении (т.е. Все еще работала отлично).

Для тех, кто пытается удалить 20 миллиардов строк из SQL Server, я настоятельно рекомендую эту статью. Соответствующий код в случае, если ссылка замирает (прочитайте статью для полного объяснения):

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 года

Если вы планируете хранить эти данные в одной таблице, не делайте этого. Я настоятельно рекомендую вам рассмотреть разбиение таблиц (либо вручную, либо со встроенными функциями, если вы используете Enterprise edition). Это уменьшает старые данные так же просто, как обрезание таблицы один раз (неделя/месяц/и т.д.). Если у вас нет Enterprise (чего у нас нет), вы можете просто написать script, который выполняется один раз в месяц, отбрасывает таблицы старше 2 лет, создает таблицу следующего месяца и восстанавливает динамическое представление, которое объединяет все таблицы разделов для упрощения запросов. Очевидно, что "раз в месяц" и "старше 2 лет" должен быть определен вами на основе того, что имеет смысл для вашего случая использования. Удаление непосредственно из таблицы с десятками миллиардов строк данных будет: a) взять ОГРОМНОЕ количество времени и б) заполнить журнал транзакций в сотни или тысячи раз.

Ответ 4

Я не знаю предела строки, но я знаю таблицы с более чем 170 миллионами строк. Вы можете ускорить его с помощью секционированных таблиц (2005+) или представлений, которые соединяют несколько таблиц.

Ответ 5

Я не знаю MSSQL специально, но 36 миллионов строк невелики для базы данных предприятия - работая с базами данных мейнфреймов, для меня 100.000 строк звучит как таблица конфигурации: -).

В то время как я не являюсь большим поклонником некоторых программ Microsoft, это не Access, о котором мы говорим здесь: я предполагаю, что они могут обрабатывать довольно значительные размеры базы данных с помощью своих корпоративных СУБД.

Я подозреваю, что дни, возможно, были слишком прекрасными, чтобы разделить его, если действительно ему нужно делить вообще.

Ответ 6

У нас есть таблицы в SQL Server 2005 и 2008 с более чем 1 миллиардом строк в нем (30 миллионов добавляются ежедневно). Я не могу себе представить, как спуститься с крыс, раскладывая их в новый стол каждый день.

Намного дешевле добавить подходящее место на диске (которое вам нужно) и RAM.

Ответ 7

Это зависит, но я бы сказал, что лучше всего держать все в одной таблице ради простоты.

100 000 строк в день на самом деле не так много. (В зависимости от вашего серверного оборудования). Я лично видел, что MSSQL обрабатывает до 100M строк в одной таблице без каких-либо проблем. Пока вы держите свои индексы в порядке, все должно быть хорошо. Ключ состоит в том, чтобы иметь кучи памяти, чтобы индексы не могли быть заменены на диск.

С другой стороны, это зависит от того, как вы используете данные, если вам нужно сделать много запросов, и потребуются маловероятные данные, которые охватывают несколько дней (так что вам не нужно будет присоединяться к таблицам) он будет быстрее разделить его на несколько таблиц. Это часто используется в таких приложениях, как управление производственными процессами, где вы можете читать значение, например, 50 000 инструментов каждые 10 секунд. В этом случае скорость чрезвычайно важна, но простота не является.

Ответ 8

Мы переполнили целочисленный первичный ключ один раз (это ~ 2,4 миллиарда строк) на таблице. Если есть ограничение по строкам, вы вряд ли когда-либо ударяете его всего за 36 миллионов строк в год.

Ответ 9

Вы можете заполнить таблицу, пока не будет достаточно места на диске. Для лучшей производительности вы можете попробовать перейти на SQL Server 2005, а затем разбить таблицу и поместить детали на разные диски (если у вас есть конфигурация RAID, которая действительно может вам помочь). Разметка возможна только в корпоративной версии SQL Server 2005. Вы можете посмотреть пример раздела по этой ссылке: http://technet.microsoft.com/en-us/magazine/cc162478.aspx

Также вы можете попытаться создать представления для большинства используемых частей данных, что также является одним из решений.

Надеюсь, это помогло...

Ответ 10

Самая большая таблица, с которой я столкнулась на SQL Server 8 на Windows2003, составила 799 миллионов с 5 столбцами. Но независимо от того, будет ли это хорошо, измерять ли он по SLA и случаю использования - например, загрузите 50-100 000 000 записей и посмотрите, все ли работает.

Ответ 11

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

Ответ 12

Разделяйте таблицу ежемесячно. Это лучший способ обработки таблиц с большим ежедневным притоком, будь то оракул или MSSQL.