Я только что испытал сбой базы данных из-за внезапной необычной загрузки данных с диска.Я обнаружил, что проблема возникнет, когда я попытался вставить в таблицу журнала с прибл.3,5 миллиона строк.В таблице имеется столбец ID, установленный в IDENTITY, но без индексов или уникальных ограничений.
CREATE TABLE [dbo].[IntegrationTestLog](
[Id] [int] IDENTITY(1,1) NOT NULL,
[Ident] [varchar](50) NULL,
[Date] [datetime] NOT NULL,
[Thread] [varchar](255) NOT NULL,
[Level] [varchar](50) NOT NULL,
[Logger] [varchar](255) NOT NULL,
[Message] [varchar](max) NOT NULL,
[Exception] [varchar](max) NULL
)
Проблема, вызванная этой строкой:
INSERT INTO IntegrationTestLog ([Ident],[Date],[Thread],[Level],[Logger],[Message],[Exception]) VALUES (@Ident, @log_date, @thread, @log_level, @logger, @message, @exception)
Возможно, существует много других запросов, которые будутвызвать его, но этот я точно знаю.
Терпите меня, потому что я только догадываюсь, но замедляется ли процесс заполнения идентификаторов, если индекс отсутствует?Может ли какой-нибудь небольшой шанс вернуться к выполнению MAX (ID) запроса, чтобы получить последнюю запись?(Возможно нет).Мне пока не удалось найти какую-либо глубокую техническую информацию по этому вопросу.Пожалуйста, поделитесь, если вам известна литература или ссылки на нее.
Чтобы решить проблему , мы усекли таблицу, которая сама по себе ОЧЕНЬ долго.Я также повысил ID до первичного ключа.Затем я прочитал эту статью: Столбцы идентификаторов и обнаружил, что усечение действительно затрагивает начальное значение идентификатора.
Таблица усечения (но не удаление) обновит текущее начальное значение до исходногоначальное значение.
... что снова привело меня к тому, что я стал более подозрительным к семени идентификации.
Снова я ищу в темноте - пожалуйста, просветите меня по этому вопросу, если у вас есть понимание.