التنقل · تعيين كصفحة رئيسية · إضافة إلى المفضلة · الهاتف المحمول Tencent · الصفحة الرئيسية لـ Tencent الأخبار مدونة المنتدى التعليقات المالية الأوراق المالية صناديق أسهم هونج كونج الترفيه النجوم الأفلام الموسيقى الرياضة NBA كرة القدم السيارات الشاملة العقارات الأجهزة المنزلية التكنولوجيا تنزيلات الهاتف المحمول الرقمية عواطف المرأة الأبوة والأمومة الأزياء التسوق السفر القراءة الأصلي التعليم الذهاب إلى الخارج، الألعاب، الرسوم المتحركة، الأبراج، الفيديو، الصور الحية، المعرض، الأعمال الخيرية، الأطفال، القرص الذهبي الصيني الشهير الجديد، قم بزيارة العالم الملون للأزياء والسلع الفاخرة، الهواتف المحمولة الوطنية الأكثر مبيعًا، اتبع قائمة التصنيف لمعرفة المشاهير الذين لديهم أعياد ميلاد اليوم الصفحة الرئيسية > التكنولوجيا والرقمية > أخبار التمرير الرقمي > النص
Catch-21 لتطوير قاعدة بيانات SQL Server http://digi.QQ.com 21 ديسمبر 2009 09:43 Zhongguancun Online إذا كنت مسؤولاً عن مشروع يعتمد على SQL Server، أو كنت جديدًا على SQL Server، فقد يكون لديك تواجه بعض مشكلات أداء قاعدة البيانات، وستزودك هذه المقالة ببعض الإرشادات المفيدة (والتي يمكن أيضًا استخدام معظمها مع أنظمة إدارة قواعد البيانات الأخرى).
هنا، لن أقدم نصائح حول استخدام SQL Server، ولا يمكنني تقديم حل شامل. ما أفعله هو تلخيص بعض الخبرة حول كيفية إنشاء تصميم جيد. تأتي هذه التجربة مما تعلمته خلال السنوات القليلة الماضية، حيث رأيت العديد من أخطاء التصميم نفسها تتكرر مرارًا وتكرارًا.
1. تعرف على الأدوات التي تستخدمها
لا تقلل من شأن هذا، فهذه هي النقطة الأكثر أهمية التي سأطرحها في هذه المقالة. ربما لاحظت أيضًا أن العديد من مبرمجي SQLServer لا يتقنون جميع أوامر T-SQL والأدوات المفيدة التي يوفرها SQLServer.
قد تقول "ماذا؟ سأضيع شهرًا في تعلم أوامر SQL التي لن أستخدمها أبدًا؟؟؟". صحيح، لا تحتاج إلى القيام بذلك. ولكن يجب عليك قضاء عطلة نهاية الأسبوع في مراجعة جميع أوامر T-SQL. مهمتك هنا هي أن تفهم أنه في المستقبل، عندما تقوم بتصميم استعلام، سوف تتذكر: "بالمناسبة، يوجد أمر يمكنه تحقيق الوظيفة التي أحتاجها بالكامل"، لذا انتقل إلى MSDN للتحقق من بناء الجملة الدقيق لـ هذا الأمر .
اسمحوا لي أن أكررها مرة أخرى: لا تستخدم المؤشرات. إذا كنت ترغب في تدمير أداء النظام بأكمله، فهي خيارك الأول الأكثر فعالية. يستخدم معظم المبتدئين المؤشرات دون أن يدركوا تأثيرها على الأداء. إنهم يشغلون الذاكرة، ويغلقون الطاولات بكل طرقهم الغريبة، ويعملون كالحلزون. وأسوأ ما في الأمر هو أنه يمكنهم إجراء كل تحسينات الأداء التي يمكن أن يقوم بها DBA الخاص بك بما يعادل عدم القيام بذلك. هل تعلم أنه في كل مرة تقوم فيها بتنفيذ FETCH، فإنك تقوم بتنفيذ أمر SELECT؟ هذا يعني أنه إذا كان المؤشر الخاص بك يحتوي على 10000 سجل، فسوف يقوم بإجراء 10000 تحديد! سيكون الأمر أكثر كفاءة إذا استخدمت مجموعة من التحديد أو التحديث أو الحذف لإكمال العمل المقابل.
يعتقد المبتدئون عمومًا أن استخدام المؤشرات هو طريقة مألوفة ومريحة أكثر للبرمجة، ولكن لسوء الحظ، قد يؤدي ذلك إلى ضعف الأداء. من الواضح أن الغرض العام من SQL هو ما تريد تحقيقه، وليس كيف.
لقد قمت ذات مرة بإعادة كتابة إجراء مخزن يعتمد على المؤشر باستخدام T-SQL. كان الجدول يحتوي على 100000 سجل فقط. استغرق الإجراء المخزن الأصلي 40 دقيقة لإكماله، لكن الإجراء المخزن الجديد استغرق 10 ثوانٍ فقط. هنا، أعتقد أنك يجب أن تكون قادرًا على رؤية ما يفعله المبرمج غير الكفء! ! !
يمكننا في بعض الأحيان كتابة برنامج صغير لاسترداد البيانات ومعالجتها وتحديث قاعدة البيانات، وهو ما يكون في بعض الأحيان أكثر كفاءة. تذكر: لا يستطيع T-SQL فعل أي شيء بخصوص الحلقات.
دعني أذكرك مرة أخرى: لا توجد فوائد لاستخدام المؤشرات. لم أر قط أي شيء يتم تنفيذه بفعالية باستخدام المؤشرات، باستثناء عمل DBA.
3. توحيد جداول البيانات الخاصة بك
لماذا لا تطبيع قاعدة البيانات؟ ربما يكون هناك عذران: أسباب الأداء والكسل المطلق. أما بالنسبة للنقطة الثانية، فسيتعين عليك دفع ثمنها عاجلاً أم آجلاً. وفيما يتعلق بالأداء، لا تحتاج إلى تحسين شيء ليس بطيئًا على الإطلاق. غالبًا ما أرى المبرمجين "يقومون بإلغاء تطبيع" قاعدة البيانات لأن السبب هو أن "التصميم الأصلي كان بطيئًا للغاية"، ولكن النتيجة غالبًا هي جعل النظام أبطأ. تم تصميم نظام إدارة قواعد البيانات للتعامل مع قواعد البيانات الأساسية، لذا تذكر: قم بتصميم قاعدة البيانات وفقًا لمتطلبات تحديد المعايير الأساسية.
4. لا تستخدم التحديد *
وهذا ليس بالأمر السهل، وأنا أعلم ذلك جيدًا، لأنني أفعل ذلك بنفسي طوال الوقت. ومع ذلك، إذا قمت بتحديد الأعمدة التي تحتاجها في SELECT، فسوف تحقق الفوائد التالية:
1 تقليل استهلاك الذاكرة وعرض النطاق الترددي للشبكة
2 يمكنك الحصول على تصميم أكثر أمانا
3 امنح مُحسِّن الاستعلام فرصة لقراءة جميع الأعمدة المطلوبة من الفهرس
الصفحة 2: فهم ما ستفعله ببياناتك
يعد إنشاء فهرس قوي لقاعدة البيانات الخاصة بك أمرًا جيدًا. ولكن القيام بذلك هو مجرد فن. كلما قمت بإضافة فهرس إلى جدول، سيكون تحديد SELECT أسرع، ولكن INSERT وDELETE سيكونان أبطأ بشكل ملحوظ لأن إنشاء الفهرس وصيانته يتطلب الكثير من العمل الإضافي. من الواضح أن مفتاح السؤال هنا هو: ما نوع العملية التي تريد تنفيذها على هذه الطاولة؟ ليس من السهل فهم هذه المشكلة، خاصة عندما يتعلق الأمر بالحذف والتحديث، لأن هذه العبارات غالبًا ما تحتوي على أوامر SELECT في الجزء WHERE.
6. لا تقم بإنشاء فهرس في عمود "الجنس".
أولاً، يجب أن نفهم كيف تعمل الفهارس على تسريع الوصول إلى الجدول. يمكنك التفكير في الفهارس كوسيلة لتقسيم الجدول بناءً على معايير معينة. إذا قمت بإنشاء فهرس في عمود مثل "الجنس"، فأنت ببساطة تقسم الجدول إلى قسمين: ذكر وأنثى. أنت تتعامل مع جدول يحتوي على 1,000,000 سجل، ما أهمية هذا التقسيم؟ تذكر: صيانة الفهارس تستغرق وقتًا طويلاً. عند تصميم الفهرس يرجى اتباع هذه القاعدة: ترتيب الأعمدة من الأكثر إلى الأقل حسب عدد المحتويات المختلفة التي قد يحتوي عليها العمود، مثل: الاسم + المحافظة + الجنس.
7. استخدم المعاملات
يرجى استخدام المعاملات، خاصة عندما تستغرق الاستعلامات وقتًا طويلاً. إذا حدث خطأ ما في نظامك، فهذا سينقذ حياتك. بشكل عام، سوف يفهم المبرمجون الذين يتمتعون ببعض الخبرة أنك غالبًا ما تواجه بعض المواقف غير المتوقعة التي قد تؤدي إلى تعطل الإجراء المخزن.
8. احذر من الجمود
الوصول إلى الجداول الخاصة بك في ترتيب معين. إذا قمت بتأمين الجدول A أولاً ثم قمت بتأمين الجدول B، فيجب تأمينه بهذا الترتيب في كافة الإجراءات المخزنة. إذا قمت (عن طريق الخطأ) بتأمين الجدول B أولاً ثم قمت بتأمين الجدول A في إجراء مخزن، فقد يؤدي ذلك إلى حالة توقف تام. إذا لم يتم تصميم تسلسل القفل بالتفصيل مسبقًا، فلن يكون من السهل اكتشاف حالة توقف تام.
السؤال المتكرر هو: كيف يمكنني إضافة 100000 سجل بسرعة إلى ComboBox؟ هذا ليس صحيحًا ولا يمكنك ولا تحتاج إلى القيام بذلك. الأمر بسيط للغاية. إذا كان على المستخدم الخاص بك تصفح 100000 سجل للعثور على السجل الذي يحتاجه، فسوف يلعنك بالتأكيد. هنا، ما تحتاجه هو واجهة مستخدم أفضل وتحتاج إلى عرض ما لا يزيد عن 100 أو 200 سجل للمستخدمين.
بالمقارنة مع المؤشرات من جانب الخادم، يمكن للمؤشرات من جانب العميل تقليل الحمل الزائد للخادم والشبكة وكذلك تقليل وقت التأمين.
11. استخدم استعلام المعلمات
في بعض الأحيان، أرى أسئلة مثل هذه في المنتدى الفني لـ CSDN: "SELECT * FROM aWHEREa.id='A'B، يحدث استثناء بسبب استعلام اقتباس مفرد، ماذا علي أن أفعل؟"، والإجابة الشائعة هي: استخدم اثنين علامات الاقتباس المفردة بدلاً من علامات الاقتباس المفردة. هذا خطأ. يعالج هذا الأعراض بدلاً من السبب الجذري، لأنك ستواجه أيضًا مثل هذه المشكلات مع الشخصيات الأخرى، ناهيك عن أنها ستتسبب في حدوث أخطاء خطيرة، بالإضافة إلى ذلك، سيمنع هذا أيضًا نظام التخزين المؤقت لـ SQL Server من العمل كما ينبغي. باستخدام استعلام المعلمات، تختفي كل هذه المشاكل.
12. استخدم قواعد البيانات الكبيرة عند برمجة البرامج
بشكل عام، لا تحتوي قاعدة بيانات الاختبار التي يستخدمها المبرمجون في التطوير على كمية كبيرة من البيانات، ولكن غالبًا ما يكون لدى المستخدم النهائي كمية كبيرة من البيانات. نهجنا المعتاد خاطئ، والسبب بسيط للغاية: محركات الأقراص الثابتة ليست باهظة الثمن الآن، ولكن لماذا لا يتم ملاحظة مشاكل الأداء حتى تصبح غير قابلة للإصلاح؟
13. لا تستخدم INSERT لاستيراد كميات كبيرة من البيانات
من فضلك لا تفعل هذا إلا إذا كان ذلك ضروريا للغاية. استخدم UTS أو BCP حتى تحصل على المرونة والسرعة بضربة واحدة.
14. انتبه لقضايا المهلة
عند الاستعلام عن قاعدة البيانات، تكون القيمة الافتراضية لقاعدة البيانات العامة صغيرة نسبيًا، مثل 15 ثانية أو 30 ثانية. تستغرق بعض الاستعلامات وقتًا أطول من هذا للتشغيل، خاصة عندما يستمر مقدار البيانات في قاعدة البيانات في التزايد.
الصفحة 3: لا تتجاهل مشكلة تعديل نفس السجل في نفس الوقت
15. لا تتجاهل مشكلة تعديل نفس السجل في نفس الوقت
في بعض الأحيان، يقوم مستخدمان بتعديل نفس السجل في نفس الوقت، وبهذه الطريقة، إذا قام المعدل الأخير بتعديل عمليات المعدل السابقة، فسيتم فقدان بعض التحديثات. التعامل مع هذا الموقف ليس بالأمر الصعب: قم بإنشاء حقل طابع زمني، والتحقق منه قبل الكتابة، ودمج التعديلات إذا كان مسموحًا به، ومطالبة المستخدم إذا كان هناك تعارض.
16. عند إدراج السجلات في جدول التفاصيل، لا تقم بتنفيذ SELECT MAX(ID) في الجدول الرئيسي
هذا خطأ شائع يسبب أخطاء عندما يقوم مستخدمان بإدخال البيانات في نفس الوقت. يمكنك استخدام SCOPE_IDENTITY وIDENT_CURRENT وIDENTITY. إذا أمكن، لا تستخدم IDENTITY لأنها يمكن أن تسبب مشاكل في وجود المحفزات (راجع المناقشة هنا).
17. تجنب تعيين الأعمدة على أنها NULLable
إذا كان ذلك ممكناً، يجب عليك تجنب جعل الأعمدة فارغة. سيقوم النظام بتخصيص بايت إضافي لكل صف من العمود NULLable، مما سيؤدي إلى زيادة حمل النظام عند الاستعلام. بالإضافة إلى ذلك، فإن جعل الأعمدة NULLable يؤدي إلى تعقيد عملية البرمجة لأنه يجب فحص هذه الأعمدة في كل مرة يتم الوصول إليها.
أنا لا أقول أن القيم الخالية هي مصدر للمشاكل، على الرغم من أن بعض الناس يعتقدون ذلك. أعتقد أن إنشاء عمود NULLable يمكن أن يعمل أحيانًا بشكل جيد إذا كان لديك "بيانات فارغة" مسموح بها في قواعد عملك، ولكن استخدام NULLable في موقف مثل الموقف أدناه يسبب مشكلة.
اسم العميل1
عنوان العميل1
البريد الإلكتروني للعميل1
اسم العميل2
عنوان العميل2
البريد الإلكتروني للعميل3
اسم العميل1
عنوان العميل2
البريد الإلكتروني للعميل3
إذا حدث هذا، فأنت بحاجة إلى تطبيع الجدول الخاص بك.
18. حاول عدم استخدام نوع البيانات TEXT
لا تستخدم TEXT إلا إذا كنت تتعامل مع مجموعة بيانات كبيرة جدًا. لأنه ليس من السهل الاستعلام عنه، فهو بطيء وسيضيع الكثير من المساحة إذا لم يتم استخدامه بشكل صحيح. بشكل عام، يمكن لـ VARCHAR التعامل مع بياناتك بشكل أفضل.
19. حاول ألا تستخدم الجداول المؤقتة
حاول ألا تستخدم الجداول المؤقتة إلا في حالة الضرورة القصوى. بشكل عام، يمكن استخدام الاستعلامات الفرعية بدلاً من الجداول المؤقتة. سيؤدي استخدام الجداول المؤقتة إلى زيادة حمل النظام، وإذا كنت تبرمج باستخدام COM+، فسيجلب لك أيضًا الكثير من المتاعب، لأن COM+ يستخدم تجمع اتصال قاعدة البيانات والجدول المؤقت موجود من البداية إلى النهاية. يوفر SQL Server بعض البدائل، مثل نوع بيانات الجدول.
20. تعلم التحليل والاستعلام
يعد SQL Server Query Analyzer أفضل صديق لك، حيث يمكنك من خلاله فهم كيفية تأثير الاستعلامات والفهارس على الأداء.
21. استخدم التكامل المرجعي
يمكن أن يؤدي تحديد المفاتيح الأساسية والقيود الفريدة والمفاتيح الخارجية إلى توفير الكثير من الوقت.