بعض طرق تحسين أداء و سرعة ال SQL_Server

[Monzer Osama]

هذه بعض طرق تحسين أداء و سرعة ال SQL_Server
ينبغي على جميع مطوري قواعد البيانات اتباع هذه النصائح ما أمكن حيث أن الفرق بالأداء - من وجه نظري - سيكون شاسع.

بالنسبة لتصميم الجداول:
1- حاول تبسيط Normalize الجداول لمرتبة التبسيط الثالثة 3NF ما أمكن، وبالتالي ستتجنب تكرار البيانات وعمليات التحديث الشاذة update anomalies وتقليل البيانات المسترجعة بواسطة الاستعلامات (بمعنى آخر تسريعها).
التبسيط سيؤدي لتقليل الأعمدة في الجدول، وبالتالي "حشر" سجلات أكثر في صفحة البيانات الواحدة، مما يعني تقليل عمليات IO المطلوية للوصول للبيانات.
ولكن التبسيط لمرتبة أعلى من الثالثة تكثر عمليات الربط joining بين الجداول (بالذات عند الاستعلام) وبالتالي تقليل الأداء.

*ملاحظة:*
إذا كانت قاعدة البيانات مخصصة للتحليل أكثر من التحديث، فقلل التبسيط، لأن الربط في حالة التبسيط قد يقلل من كفاءة وسرعة تحليل البيانات.

2- إذا كانت قاعدة البيانات تحوي الكثير من البيانات، فقسم البيانات أفقيا partition data horizontally ، مثلا قسم بيانات الجدول لجدولين أحدهما يحوي بيانات السنة الحالية والآخر يحوي البيانات القديمة، مما يحصر البيانات المطلوبة غالبا في السنة الحالية ويقلل كمية البيانات المسترجعة، مما يعني تقليل عمليات IO.

3- حاول تقليل البيانات المسترجعة في الاستعلامات، أو بكلمة أخرى لاتفتح recordsets ضخمة، وذلك بوضع مزيد من الشروط في جزء where من جملة select.

4- إذا كان ممكنا استعمل القيود العلائقية بين البيانات relational constraints بدلا من استعمال الTriggers و الrules و الdefaults، لقابلية الخطأ الكبيرة فيها عندما تستعمل لمحاكاة القيود العلائقية.
أيضا إذا أمكن استعمل القيود العلائقية المتتالية cascading relational constraints بدلا من الtriggers، فعمل حذف متتالي cascading delete أو تحديث متتالي cascading update لايتطلب أكثر من فقرة on delete أو فقرة on update في جزء references من جملة create table أو alter table بدلا من كتابة Trigger مخصص لذلك وقضاء وقت آخر في عمل debugging له.
5- حاول التقليل بقدر الإمكان من وجود الnull values ، لإنها تعني إما القيمة غير موجودة أو غير معروفة، وتسبب أخطاء في حال استعمال دوال حسابية.

6- حاول تضييق أحجام حقول الجدول، ليقلل حجم الحقل، وبالتالي يقلل حجم الجدول، مما يعني تسريع الاستعلامات.
كيف أضيقها؟
- إذا كنت ستخزن أرقاما صحيحة ما بين 0-255 ، استعمل النوع tinyint (يحتاج ل1 بايت فقط).
-إذا كنت ستخزن أرقاما صحيحة ما بين -32768 إلى 32767 ، استعمل النوع smallint(يحتاج ل2 بايت فقط).
-إذا كنت ستخزن أرقاما صحيحة ما بين -2147483648 إلى 2147483647 ، استعمل النوع int(يحتاج ل4 بايت، قارن !)

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

- إذا كنت ستخزن تواريخ ما بين 1/1/1900 إلى 6/6/2079 مع دقة لمستوع الدقيقة فاستعمل النوع smalldatetime (يحتاج ل4 بايت فقط) أما إذا كان مدى التواريخ أبعد أو كان مطلوبا دقة أكبر فاستعمل النوع datetime (يحتاج ل8 بايت، قارن).


- استعمل النوعين varchar و nvarchar بدلا من النوعين char و nchar بقدر الإمكان، لأن النوعين الأخيرين يبذران الحيز التخزيني في مسافات فارغة .

- استعمل النوعين varchar و nvarchar بدلا من text/ntext بقدر الإمكان، لأن محرك قاعدة البيانات يخزن صفحات البيانات data pages المخصصة للنوعين Text/Image بعيدا عن صفحات البيانات المخصصة للأنواع الأخرى.
لذا فالوصول للنوعين text/ntext سيستغرق وقتا إضافيا.

أحببت أن أنقل لكم هذه المقالة لعلها تفيد

[tech4t]

بارك الله فيك اخوى
واسمحلى بحفظ الصفحة للرجوع اليها لاحقا

[msasm]

جزاكم الله خيرا بس اخي وما هو دور rebuild index حيث اني اعمل علي قواعد بيانات اوراكل وما لها من تاثير كبير علي سرعة الوصول للبيانات والاستعلامات