Чи є "уникнути створення кластерного індексу на основі ключа, що збільшується" міфом з SQL Server 2000 днів?

Наші бази даних складаються з безлічі таблиць, більшість з яких використовують цілий сурогатний ключ в якості основного ключа. Близько половини цих первинних ключів знаходяться в стовпцях ідентичності.

Розробка бази даних розпочалася ще за часів SQL Server 6.0.

Одне з правил, яке слід було спочатку: Уникайте створення кластерного індексу на основі ключа , що збільшується , як ви знайдете в цих підказках щодо оптимізації індексу .

Тепер, використовуючи SQL Server 2005 та SQL Server 2008, у мене сильне враження, що обставини змінилися. Тим часом ці стовпчики первинного ключа є ідеальними першими кандидатами для кластерного індексу таблиці.

Міф сходить до SQL Server 6.5, який додав блокування рівня рядків . І натякнув тут Кален Ділейні .

Це було пов'язано з "гарячими точками" використання сторінок даних та тим, що була заблокована ціла сторінка 2k (SQL Server 7 та версії 8k), а не вставлений рядок Редагувати, лютий 2012

Знайдена авторитетна стаття Кімберлі Л. Тріпп

"Кластерні дебати в індексах тривають ..."

Точкові точки - це те, що ми сильно намагалися уникнути PRIOR на SQL Server 7.0 через блокування рівня сторінки (і саме тут термін «гаряча точка» став негативним терміном). Насправді це не повинно бути негативним терміном. Однак, оскільки механізм зберігання даних був перестановлений / перероблений (у SQL Server 7.0) і тепер включає справжнє блокування рівня рядків, ця мотивація (щоб уникнути точкових точок) вже не існує.

Редагувати, травень 2013 року

Посилання у відповіді lucky7_2000, здається, говорить про те, що гарячі точки можуть існувати, і вони викликають проблеми. Однак у статті використовується унікальний кластерний індекс на TranTime. Для цього потрібно додати уніфікатор. Що означає індекс не суворо монотонно зростаючого (і занадто широкого). Посилання у цій відповіді не суперечить цій відповіді чи моїм посиланням

На особистому рівні я прокинувся в базах даних, де я вставляв десятки тисяч рядків в секунду в таблицю, в якій стовпчик bigint ІДЕНТИЧНОСТІ як кластеризований ПК.

Підсумовуючи це, у сучасних версіях SQL Server в даний час кращим варіантом є кластерний ключ у стовпчику ідентичності.

У Кімберлі Трипп є фантастична публікація в блозі про цю тему. Я міг би перефразувати, але повірте, я б не робив це справедливо. Прочитайте. http://www.sqlskills.com/BLOGS/KIMBERLY/post/Ever-increasing-clustering-key-the-Clustered-Index-Debateagain!.aspx

Перебуваючи там, перегляньте кілька інших її публікацій на тему кластеризації ключів. З її сайту є хороше багатство знань.

перевірити цю публікацію:

http://blogs.msdn.com/b/sqlserverfaq/archive/2010/05/27/monotonically-increasing-clustered-index-keys-can- why-latch-contention.aspx

створення кластерного індексу на основі приросту ключа може створити гарячі точки, які погані для продуктивності ...