it-swarm.asia

كيف تؤثر الأعمدة الطويلة على الأداء واستخدام القرص؟

في مشروعنا الحالي ، يحدث ذلك كثيرًا جدًا ، حيث نحتاج إلى تمديد الأعمدة بمقدار حرفين. من varchar(20) إلى varchar(30) وهكذا.

في الحقيقة ، ما مدى أهمية ذلك حقًا؟ ما مدى جودة هذا التحسين؟ ما هو تأثير السماح فقط بـ 100 أو 200 أو حتى 500 حرف لحقول "الإدخال" العادية؟ يمكن أن يحتوي البريد الإلكتروني على 320 حرفًا فقط ، لذلك لا بأس - هناك حد جيد هناك. ولكن ما الذي أكسبه إذا قمت بتعيينه على 200 ، لأنني لا أتوقع عناوين بريد إلكتروني أطول من ذلك.

عادة لن تحتوي طاولاتنا على أكثر من 100.000 صف ، وما يصل إلى 20 أو 30 عمودًا من هذا القبيل.

نستخدم SQL Server 2008 الآن ، ولكن سيكون من المثير للاهتمام معرفة كيفية معالجة قواعد البيانات المختلفة لهذه المشكلات.

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

في هذه الحالة ، أنا هنا لأتعلم :-)

27
Lars Corneliussen

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

التنسيق ستتطلب أي أداة عميل تقوم بتنسيق البيانات بناءً على حجم الحقول اعتبارات تنسيق خاصة. تعرض Oracle SQL SQL Plus على سبيل المثال افتراضيًا الحجم الأقصى لأعمدة Varchar2 حتى إذا كانت البيانات تتكون من حرف واحد فقط. قارن…

create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;

البيانات السيئة يوفر طول الحقل آلية إضافية لالتقاط/منع البيانات السيئة. يجب ألا تحاول الواجهة إدراج 3000 حرف في حقل 100 حرف ، ولكن إذا تم تعريف هذا الحقل على أنه 4000 حرف ، فقد يكون الأمر كذلك. لن يتم اكتشاف الخطأ في مرحلة إدخال البيانات ، ولكن قد يواجه النظام مشكلة أخرى عندما يحاول تطبيق آخر معالجة البيانات والاختناقات. كمثال ، إذا قررت لاحقًا فهرسة الحقل في Oracle ، فستتجاوز الحد الأقصى لطول المفتاح (اعتمادًا على حجم الكتلة والتسلسل). نرى…

create index i1 on f1(a);

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

التوثيق يوفر حجم الحقل نقطة بيانات أخرى للوثائق حول البيانات. يمكننا استدعاء جميع الجداول t1 و t2 و t3 وما إلى ذلك وجميع الحقول f1 و f2 و f3 وما إلى ذلك ، ولكن بتحديد الأسماء ذات المعنى نفهم البيانات بشكل أفضل. على سبيل المثال ، إذا كان جدول العناوين لشركة لديها عملاء في الولايات المتحدة يحتوي على حقل يسمى State يتكون من حرفين ، فإننا نتوقع أن يكون اختصار حالة الحرفين فيه. من ناحية أخرى إذا كان الحقل مائة حرف ، فقد نتوقع أن يدخل اسم الحالة الكاملة في الحقل.


بعد كل ما قيل ، يبدو من الحكمة الاستعداد للتغيير. فقط لأن جميع أسماء منتجاتك التي تتسع لـ 20 حرفًا اليوم لا تعني أنها ستظل كذلك دائمًا. لا تفرط في السعر واجعلها 1000 ، ولكن اترك مساحة للتوسع المعقول.

12
Leigh Riffel

هنا نقطة انطلاق جيدة لك.

http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx

ربما أساءت فهم سؤالك الأصلي. دعني أرى ما إذا كان بإمكاني العثور على بعض الروابط الأخرى كمرجع.

فيما يلي مرجع جيد لتحديدات نوع البيانات: http://sqlfool.com/2009/05/performance-considerations-of-data-types/

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

فيما يلي ارتباط لهياكل قاعدة البيانات: http://technet.Microsoft.com/en-us/sqlserver/gg313756.aspx

هنا واحد لتقسيم الصفحة وتسجيل trx: http://sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx

HTH

9
SQLRockstar

اعتقدت أنني سأشارك نقطة أخرى مثيرة للاهتمام ، والتي وجدتها في سؤال Stack Overflow .

الإجابة الأصلية بقلم: نيك كافادياس

سبب عدم استخدام الحقول القصوى أو النصية هو أنه لا يمكنك إجراء إعادة بناء الفهرس عبر الإنترنت أي إعادة البناء مع ONLINE = ON حتى مع SQL Server Enterprise Edition.

سأعتبر هذا عيبًا كبيرًا عند إضافة أعمدة n/varchar (max) بشكل تعسفي ، ووفقًا لموقع MS ، يظل هذا القيد ضد إعادة إنشاء الفهرس عبر الإنترنت في SQL Server 2008 و 2008 R2 ودينالي ؛ لذلك لا يقتصر على SQL Server 2005.

7
Jeff

في بعض الحالات ، سيؤثر مقدار المساحة التي تخصصها لحقل varchar على مقدار الذاكرة المخصصة لأنواع الذاكرة الداخلية.

لقد وجدت العروض التقديمية في SQLWorkshops.com مثيرة للتفكير ، يتحدث هذا العرض التقديمي عن حالة حيث ينتقل نوع أمر ما إلى tempdb لأنه لا يتم تخصيص ذاكرة كافية لحقول char/varchar.

http://webcasts2.sqlworkshops.com/webcasts.asp

كما تم عرض هذا البث الشبكي كمقالة على الموقع التالي:

http://www.mssqltips.com/tip.asp؟tip=1955

لاحظ في هذا العرض أن العمود الذي يتم فرزه ليس عمود char/varchar ، ولكن مقدار المساحة المخصصة لعمود varchar في الذاكرة يحدث فرقًا في أداء الاستعلام في بعض الحالات.

6
Jeff

هل تريد تعيين ANSI_PADDING ON؟

ينتهي بك الأمر مع الكثير من المسافات البيضاء الزائدة ...

4
gbn

لا يهم سوى مساحة القرص وطول الحرف. بالطبع البحث في أنواع البيانات والفهارس char على هذا النوع من البيانات ستعمل أبطأ من العدد الصحيح ولكن هذه مناقشة أخرى.

نوع بيانات Varchar هو نوع بيانات "متغير" ، لذا إذا قمت بإعداد حد varchar (500) من هذا الحد الأقصى لطول هذا الحقل. يمكن أن يكون الحد الأدنى للطول بين 0 و 500. من ناحية أخرى ، ستكون مساحة القرص المطالب بها مختلفة لحقول 10 أو 30 أو 500 حرف.

قمت في بعض الأحيان باختبار لنوع البيانات varchar (800) وللقيم الفارغة ، كان لدي 17 بايت مستخدمة ، ولكل حرف تم إدراجه ، أضافه بايت إضافي واحد. على سبيل المثال ، تحتوي السلسلة المكونة من 400 حرف على 417 بايت مستخدمة على القرص.

2
yrushka

لا أعتقد أن هناك أي فرق بين الجداول التي تم إنشاؤها باستخدام أعمدة varchar (20) أو varchar ((8000) ، طالما أن الطول الأقصى الفعلي هو <= 20.

على الجانب الآخر ، في بعض الحالات ، قد يمنح المستخدمون إمكانية تخزين سلاسل أطول لهم القيام بذلك.

2
bernd_k