اعتبارات أداء SQL Server
اعتبارات أداء SQL Server
اعتبارات أداء SQL Server
في هذا المنشور ، نناقش الأشياء التي نحتاج إلى وضعها في الاعتبار أثناء التعامل مع أنواع البيانات في SQL Server عندما يتعلق الأمر بالأداء وأفضل الممارسات.
النقاط أدناه قابلة للتطبيق ليس فقط على SQL Server ولكن أيضًا على RDBMS SQL الأخرى مثل Oracle و Sybase و Greenplum .. إلخ.
فيما يلي سنناقش اعتبارات أداء SQL Server
1_ حدد دائمًا أضيق الأعمدة الممكنة.
كلما كان العمود أضيق ، قل مقدار البيانات التي يجب على SQL Server تخزينها ، ويمكن لـ SQL Server قراءة البيانات وكتابتها بشكل أسرع.
بالإضافة إلى ذلك ، إذا كان يجب إجراء أي نوع على العمود ، فكلما كان العمود أضيق ، كان الفرز أسرع.
2_ إذا كنت بحاجة إلى تخزين سلاسل كبيرة من البيانات وأقل من 8000 حرف ، فاستخدم نوع بيانات VARCHAR بدلاً من نوع بيانات TEXT.
تحتوي أنواع بيانات TEXT على الحمل الإضافي الذي يؤدي إلى انخفاض الأداء.
3_ لا تستخدم أنواع بيانات NVARCHAR أو NCHAR إلا إذا كنت بحاجة إلى تخزين بيانات ذات أحرف 16 بت (Unicode).
تشغل مساحة ضعف مساحة بيانات VARCHAR أو CHAR ، مما يزيد من إدخال / إخراج الخادم وإهدار مساحة غير ضرورية في ذاكرة التخزين المؤقت.
4_ إذا كانت البيانات النصية في عمود تختلف اختلافًا كبيرًا في الطول ، فاستخدم نوع بيانات VARCHAR بدلاً من نوع بيانات CHAR.
يمكن أن يقلل مقدار المساحة المحفوظة باستخدام VARCHAR عبر CHAR على أعمدة متغيرة الطول بشكل كبير ذاكرة التخزين المؤقت لقراءة الإدخال / الإخراج المستخدمة للاحتفاظ بالبيانات ، مما يؤدي إلى تحسين أداء SQL Server بشكل عام.
5_ ميزة أخرى لاستخدام VARCHAR على أعمدة CHAR هي أن الفرز التي يتم إجراؤها على أعمدة VARCHAR تكون بشكل عام أسرع من أعمدة CHAR.
6_ هذا لأن العرض الكامل لعمود CHAR يحتاج إلى الفرز.
7_ إذا كانت بيانات العمود لا تختلف اختلافًا كبيرًا من حيث الطول ، ففكر في استخدام حقل CHAR بطول ثابت بدلاً من VARCHAR.
بينما قد يستغرق الأمر مساحة أكبر قليلاً لتخزين البيانات ، فإن معالجة الأعمدة ذات الطول الثابت تكون أسرع في SQL Server من معالجة الأعمدة متغيرة الطول.
8_ اختر دائمًا أصغر نوع بيانات تحتاجه للاحتفاظ بالبيانات التي تريد تخزينها في عمود.
على سبيل المثال ، إذا كان كل ما ستقوم بتخزينه في عمود هو الأرقام من 1 إلى 10 ، فإن نوع بيانات TINYINT يكون أكثر ملاءمة من نوع البيانات INT.
الشيء نفسه ينطبق على أنواع البيانات CHAR و VARCHAR. لا تحدد المزيد من الأحرف في أعمدة الأحرف التي تحتاجها.
يتيح لك ذلك تخزين المزيد من الصفوف في صفحات البيانات والفهرس ، مما يقلل من كمية الإدخال / الإخراج اللازمة لقراءتها.
كما أنه يقلل من كمية البيانات المنقولة من الخادم إلى العميل ، مما يقلل من حركة مرور الشبكة والكمون.
كما أنه يقلل من مقدار المساحة المهدورة في ذاكرة التخزين المؤقت.
9_ إذا كان لديك عمود مصمم ليحتوي على أرقام فقط
فاستخدم نوع بيانات رقمي ، مثل INTEGER ، بدلاً من نوع بيانات VARCHAR أو CHAR.
تتطلب أنواع البيانات الرقمية عمومًا مساحة أقل للاحتفاظ بنفس القيمة الرقمية مثل نوع بيانات الحرف.
يساعد هذا في تقليل حجم الأعمدة ، ويمكن أن يعزز الأداء عند البحث في الأعمدة (جملة WHERE) ، أو ربطها بعمود آخر ، أو فرزها.
10_ تجنب استخدام أنواع البيانات FLOAT أو REAL للمفاتيح الأساسية ، لأنها تضيف عبئًا غير ضروري يضر بالأداء.
استخدم أحد أنواع بيانات الأعداد الصحيحة بدلاً من ذلك.
11_ عند تحديد أنواع البيانات أثناء إنشاء الجدول ، حدد دائمًا NULL أو NOT NULL لكل عمود.
إذا لم تقم بذلك ، فسيتم تعيين العمود افتراضيًا إلى NOT NULL إذا لم يتم تحديد خيار قاعدة بيانات ANSI NULL DEFAULT (الافتراضي) ،
وسيتم افتراضيًا إلى NULL إذا تم تحديد خيار قاعدة بيانات ANSI NULL DEFAULT.
12_ للحصول على أفضل أداء ، ولتقليل الأخطاء البرمجية المحتملة ، يجب بشكل مثالي تعيين الأعمدة على NOT NULL.
على سبيل المثال ، استخدام الكلمات الأساسية IS NULL في جملة WHERE يجعل هذا الجزء من الاستعلام غير قابل للرسوم ،
مما يعني أن هذا الجزء من الاستعلام لا يمكنه الاستفادة من الفهرس.
13_ إذا كنت تستخدم أعمدة ذات طول ثابت (CHAR ، NCHAR) في جدولك ، ففكر في تجنب تخزين القيم الفارغة فيها.
إذا قمت بذلك ، فسيتم استخدام كامل المساحة المخصصة للعمود.
على سبيل المثال ، إذا كان لديك عمود بطول ثابت مكون من 255 حرفًا وقمت بوضع NULL فيه ، فيجب تخزين 255 حرفًا في قاعدة البيانات.
هذا هو إهدار كبير للمساحة التي ستجعل SQL Server يضطر إلى تنفيذ قرص إضافي I / O لقراءة صفحات البيانات.
كما أنه يهدر مساحة في المخزن المؤقت لذاكرة التخزين المؤقت للبيانات. كلاهما يساهم في انخفاض أداء SQL Server.
14_ إذا كنت تستخدم الدالة CONVERT لتحويل قيمة إلى نوع بيانات متغير الطول
مثل VARCHAR ، فحدد دائمًا طول نوع البيانات المتغير. إذا لم تقم بذلك ، يفترض SQL Server أن الطول الافتراضي هو 30.
بشكل مثالي ، يجب عليك تحديد أقصر طول لإنجاز المهمة المطلوبة. هذا يساعد على تقليل استخدام الذاكرة وموارد SQL Server.
15_ بشكل عام ، لا يُنصح باستخدام الأعمدة المحسوبة في جدول لأنه لا يتبع القواعد القياسية للتطبيع.
ولكن في بعض الأحيان يكون استخدام الأعمدة المحسوبة في جدول أكثر فاعلية بشكل عام بدلاً من إعادة حساب البيانات نفسها بشكل متكرر في الاستعلامات.
هذا صحيح بشكل خاص إذا كنت تقوم بتشغيل نفس الاستعلام مرارًا وتكرارًا مقابل بياناتك التي تؤدي نفس الحسابات مرارًا وتكرارًا.
يمكن أن يؤدي إجراء العمليات الحسابية في الجدول إلى تقليل مقدار العمل الذي يتم تنفيذه بواسطة استعلام في كل مرة يتم تشغيله فيها.
عليك أن تحدد بنفسك أين تكمن عنق الزجاجة في الأداء ، وتتصرف وفقًا لذلك.
إذا كان عنق الزجاجة في INSERTS و UPDATES ، فقد لا يكون استخدام الأعمدة المحسوبة فكرة جيدة.
ولكن إذا كانت عبارات SELECT الخاصة بك هي عنق الزجاجة ، فإن استخدام الأعمدة المحسوبة قد يؤتي ثماره.
16_ تجنب استخدام نوع البيانات الكبيرة إلا إذا كنت بحاجة فعلاً إلى سعة تخزين إضافية.
يستخدم نوع بيانات bigint 8 بايت من الذاكرة مقابل 4 بايت لنوع البيانات int.
17_ تجنب استخدام نوع البيانات SQL Server sql_variant.
إلى جانب كونه خنزيرًا في الأداء ، فإنه يؤثر بشكل كبير على ما يمكنك فعله بالبيانات المخزنة كمتغير sql.
18_ على سبيل المثال ، لا يمكن أن تكون أعمدة sql_variant جزءًا من المفاتيح الأساسية أو الخارجية
ويمكن استخدامها في الفهارس والمفاتيح الفريدة إذا كانت أقل من 900 بايت ،
ولا يمكن أن تحتوي على خاصية هوية ، ولا يمكن أن تكون جزءًا من عمود محسوب ،
ويجب تحويل البيانات إلى نوع بيانات آخر عند نقل البيانات إلى كائنات ذات أنواع بيانات أخرى ،
يتم تحويلها تلقائيًا إلى nvarchar (4000) عند الوصول إليها بواسطة تطبيقات العميل باستخدام موفري SQL Server 7.0 OLE DB أو ODBC ،
غير مدعومة من قبل المسند LIKE في جملة WHERE ، ولا يمكن ربطها ، ولا تعمل مع بعض الوظائف.
19_ تجنب استخدام أنواع بيانات التاريخ كمفتاح أساسي.
من منظور الأداء ، من الأفضل استخدام نوع بيانات يستخدم مساحة أقل.
على سبيل المثال ، يستخدم نوع البيانات DATETIME 8 بايت من المساحة ، بينما يستغرق نوع البيانات INT 4 بايت فقط.
كلما قلت المساحة المستخدمة ، كلما كان الجدول والفهرس أصغر ، وكلما قل حجم الإدخال / الإخراج المطلوب للوصول إلى المفتاح الأساسي.
20_ إذا كنت تقوم بإنشاء عمود تعرف أنه سيخضع لأنواع عديدة
ففكر في جعل العمود مستندًا إلى عدد صحيح وليس قائمًا على الأحرف. وذلك لأن SQL Server يمكنه فرز بيانات عدد صحيح أسرع من بيانات الأحرف.
في الختام
ناقشنا في هذه المقالة اعتبارات أداء SQL Server كل ما يتعلق بأداء و أنظمة التشغيل SQL Server
تابع باقي سلسلة مقالات لغات البرمجة وقواعد البيانات في مدونتنا
تواصل معنا واطلب الخدمة الاحترافية من المهندسين المختصين