كيف يمكنني تقدير أحجام فهرس SQL Server

Question

في حين أن تقدير أحجام الصفوف والجداول المستقيمة يعد عملية حسابية بسيطة إلى حد ما، إلا أننا نجد صعوبة في تخمين مقدار المساحة التي سيشغلها كل فهرس (لحجم جدول معين).ما هي المجالات التي يمكن أن نتعلمها لحساب تقدير أفضل ومعدل نمو للمؤشرات؟

Answer 1

تحتوي صفحة الفهرس على مقدمة تحدد صفحة البيانات (7 بايت بالإضافة إلى بعض معلومات الدليل للأعمدة ذات الطول المتغير، إن وجدت) بالإضافة إلى نسخة من قيمة (قيم) المفتاح والتي ستكون بنفس حجم بيانات الجدول لتلك الأعمدة.هناك واحد لكل صف في الجدول.تكون المستويات الأعلى للفهرس أصغر بكثير، وعادة ما تكون أقل من 1% من الأوراق إلا إذا كنت تقوم بفهرسة مفتاح واسع جدًا.

يترك عامل التعبئة بعض المساحة خالية حتى لا تؤدي التحديثات والإدراجات إلى إنشاء حركة مرور مفرطة لتقسيم الأوراق.

يحرر: رابط MSDN هذا يصف الهياكل على مستوى الصفحة، على الرغم من أنه يسلط الضوء قليلاً على تنسيق صفوف الفهرس الفردية. هذا العرض ينتقل إلى التنسيق الفعلي لإدخالات سجل القرص وصفحات البيانات إلى حد ما. هذا مزيد من التفاصيل ويتضمن هياكل بيانات الفهرس.الأعمدة الرقمية والثابتة الطول لها الحجم المذكور على الصندوق؛سيكون عليك تقدير متوسط ​​حجم أعمدة varchar.

كمرجع، يمكن العثور على بعض المستندات بتنسيق كتلة Oracle هنا و هنا.

Answer 2

وعندما يكون ذلك ممكنا، وأنا عموما تأخذ 1000 سجل من الجدول الأصلي، إدراجها في الجدول الخاص بي، ومع البرنامج النصي أدناه لدي عينة للعب مع.

وطيب أنها ليست دقيقة، ولكن يمكن أن تعطيني نقطة انطلاق.

--Find out the disk size of an index:
--USE [DB NAME HERE]
go
SELECT
OBJECT_NAME(I.OBJECT_ID) AS TableName,
I.name AS IndexName,   
8 * SUM(AU.used_pages) AS 'Index size (KB)',
CAST(8 * SUM(AU.used_pages) / 1024.0 AS DECIMAL(18,2)) AS 'Index size (MB)'
FROM
sys.indexes I
JOIN sys.partitions P ON P.OBJECT_ID = I.OBJECT_ID AND P.index_id = I.index_id
JOIN sys.allocation_units AU ON AU.container_id = P.partition_id
--WHERE 
--    OBJECT_NAME(I.OBJECT_ID) = '<TableName>'    
GROUP BY
I.OBJECT_ID,    
I.name
ORDER BY
TableName

--========================================================================================

--http://msdn.microsoft.com/en-us/library/fooec9de780-68fd-4551-b70b-2d3ab3709b3e.aspx

--I believe that keeping the GROUP BY 
--is the best option in this case
--because of sys.allocation_units
--can have 4 types of data inside
--as below:

--type tinyint
--Type of allocation unit.
--0 = Dropped
--1 = In-row data (all data types, except LOB data types)
--2 = Large object (LOB) data (text, ntext, image, xml, large value types, and CLR     user-defined types)
--3 = Row-overflow data

--marcelo miorelli 8-NOV-2013
--========================================================================================