المجموع الاختباري() التصادم في SQL Server 2005

Question

لدي جدول 5,651,744 الصفوف ، مع مفتاح أساسي مصنوع من 6 أعمدة (int x 3, عدد صحيح صغير, varchar(39), varchar(2)).أنا أتطلع إلى تحسين الأداء مع هذا الجدول جدول آخر الذي أسهم هذا المفتاح الأساسي بالإضافة إلى إضافة عمود ولكن 37m الصفوف.

تحسبا إضافة عمود إلى إنشاء التجزئة الرئيسية ، أنا عملت تحليل ووجدت 18,733 التصادم.

SELECT  SUM(CT)
FROM    (
         SELECT HASH_KEY
               ,COUNT(*) AS CT
         FROM   (
                 SELECT CHECKSUM(DATA_DT_ID, BANK_NUM, COST_CTR_NUM,
                                 GL_ACCT_NUM, ACCT_NUM, APPN_CD) AS HASH_KEY
                 FROM   CUST_ACCT_PRFTBLT
                ) AS X
         GROUP BY HASH_KEY
         HAVING COUNT(*) > 1
        ) AS Y

SELECT  COUNT(*)
FROM    CUST_ACCT_PRFTBLT

إنه عن ضعف سيئة مع BINARY_CHECKSUM()

هل تبدو هذه عالية جدا (.33%) نظرا أصغر النسبية كمية من الوجهة الفضاء أنا مكانه؟ -و إذا كان التصادم هذا هل هناك فائدة في الانضمام إلى هذا المصنعة الرئيسية الأولى في ينضم تكلفة إضافية 4 بايت لكل صف ، بالنظر إلى أن كنت لا تزال لديك للانضمام على أعمدة منتظمة إلى التعامل مع عرضية الاصطدام ؟

Answer 1

وأنا لا أرى فيها إضافة الاختباري سوف تحصل على أي شيء مع هذا المستوى من collisons. حتى 1 الاصطدام هو عدد كبير جدا لأن من شأنه أن يسبب لك للانضمام إلى بيانات خاطئة. إذا كنت لا تستطيع أن تضمن أن يكون الانضمام إلى السجل الصحيح، فمن غير المجدي إذا كان يحسن الأداء ولكن عبث مع سلامة البيانات. ويبدو أن هذا البيانات المالية، لذلك كنت قد يكون أفضل متأكدا أن استفساراتكم لن يعود النتائج السيئة. هل يمكن فعلا في نهاية المطاف خصم أو الاعتماد على حسابات خاطئة إذا كان هناك أي تصادم.

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

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

Answer 2

ما رأيت الكثير من الناس تتستر على حتى الآن هو أن CHECKSUM وقد طن من الاصطدامات ، مايكروسوفت القبول الخاصة.إنه أسوأ حتى من MD5, التي لها حصة عادلة من معنى التصادم.

إذا كنت تبحث للحصول على تجزئة العمود, النظر في استخدام HASHBYTES مع SHA1 المحدد. SHA1 لديه الكثير أقل وضوحا من الاصطدامات MD5 أو CHECKSUM.لذلك ، CHECKSUM لا ينبغي أبدا أن تستخدم لتحديد ما إذا كان الصف هي فريدة من نوعها ، بل إنه فحص سريع على الإخلاص القيمتين.فإن الاصطدام ينبغي أن يكون معدل 0% مع HASHBYTES, إلا إذا كان لديك الصفوف المكررة (والتي يجري PK, ينبغي أن يحدث أبدا).

نضع في اعتبارنا أن HASHBYTES سيتم اقتطاع أي شيء أكبر من 8000 بايت لكن PK هو الكثير أقل من ذلك (كل متصلا), لذلك يجب أن لا يكون أي مشكلة.

Answer 3

إذا الاختباري يحصل على ذلك وصولا الى 0.33٪ من البيانات، ثم يهمني القول انها تعمل بشكل جيد ... خاصة إذا كنت تستخدم هذا العمود في تركيبة مع الأعمدة الأخرى (فهرستها).

وبطبيعة الحال، أن تكون فعالة وذلك في مؤشر ربما كنت ترغب في حساب وتخزين هذه القيمة عند إدخال / تحديث البيانات، مع عدم عنقودية مؤشر.

وبطبيعة الحال، تمتد مؤشر منتظم على مدى الأعمدة في السؤال قد يفعل كذلك أو أفضل ...

Answer 4

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

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

وكنت ترغب في تحسين للمؤشر نسعى إليه. الاختباري هو بالفعل انتقائية للغاية. مضيفا أن FKS زيادة حجم مؤشر والمقابلة I / O، ولن يساعد إلا أنها شملت مجالات أخرى كافية لتجنب المرجعية بحث تماما.

ومنذ فهرس غير متفاوت سوف تحتوي على مفاتيح التجميع أو مؤشر كتلة، وتريد إما) مفتاح تجمع صغير (على سبيل المثال، عمود هوية الباحث - 4 بايت المؤشر) أو ب) لا فهرس مجمع على الإطلاق (8 مؤشر بايت).

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

إذا كنت قادرا على دفع تكاليف التخزين والفهرسة، على بعد بضعة مؤشرات تغطية - رأس والتفاصيل -. قد يكون وسيلة للذهاب

Answer 5

إذا كان الخاص بك PRIMARY KEY هو متفاوت ، ثم كل مؤشر إنشاء تحتوي على هذا PRIMARY KEY.

الانضمام على تجزئته قيمة استخدام هذه الخطوات التالية:

1. موقع تجزئته القيمة في مفتاح المؤشر
   • موقع PRIMARY KEY قيمة مؤشر البيانات
   • استخدام Clustered Index Seek لتحديد موقع PRIMARY KEY صف في الجدول

الانضمام على PRIMARY KEY سوف تستخدم فقط خطوة 3.

SQL Server, بيد أنه ذكي بما فيه الكفاية أن تأخذ هذا في الاعتبار ، إذا كنت ستنضم مثل هذا:

SELECT  *
FROM    main_table mt
JOIN    CUST_ACCT_PRFTBLT cap
ON      cap.HASH_KEY = mt.HASH_KEY
        AND cap.DATA_DT_ID = mt.DATA_DT_ID
        AND …
WHERE   mt.some_col = @filter_value

, ، فإنه ليس فقط استخدام مؤشر على HASH_KEY, بدلا من ذلك أنها سوف تستخدم واحدة Clustered Index Seek و Filter للتأكد من قيم التجزئة مباراة (وهم دائما).

ملخص:مجرد الانضمام على PRIMARY KEY.

باستخدام الثانوية مؤشر, سوف تحتاج أولا إلى القيام عديمة الفائدة HASH_KEY بحث ثم لا تزال بحاجة إلى الانضمام على PRIMARY KEY.