كيفية تحسين الأداء في جدول SQL Server مع حقول الصور؟

Question

أواجه مشكلة أداء خاصة جدًا في العمل!

يوجد في النظام الذي نستخدمه جدول يحتوي على معلومات حول عملية سير العمل الحالية.يحتوي أحد الحقول على جدول بيانات يحتوي على بيانات وصفية حول العملية (لا تسألني لماذا!!ولا أستطيع تغييره!!)

تكمن المشكلة في تخزين جدول البيانات هذا في حقل IMAGE في SQL Server 2005 (ضمن قاعدة بيانات متوافقة مع SQL 2000).

يحتوي هذا الجدول حاليًا على أكثر من 22 ألف سطر وحتى استعلام بسيط مثل هذا:

SELECT TOP 100 *
  FROM OFFENDING_TABLE

يستغرق 30 ثانية لاسترداد البيانات في محلل الاستعلام.

أفكر في تحديث التوافق مع SQL 2005 (بمجرد أن علمت أن التطبيق يمكنه التعامل معه).

الشيء الثاني الذي أفكر فيه هو تغيير نوع بيانات العمود إلى varbinary(max) لكني لا أعرف إذا كان القيام بذلك سيؤثر على التطبيق.

الشيء الآخر الذي أفكر فيه هو استخدامه sp_tableoption لتعيين large value types out of row ل 1 كما هو الحال حاليا 0, ، ولكن ليس لدي معلومات إذا كان القيام بذلك سيؤدي إلى تحسين الأداء.

هل يعرف أحد كيفية تحسين الأداء في مثل هذا السيناريو؟

---

تم التعديل للتوضيح

مشكلتي هي أنه ليس لدي أي سيطرة على ما يطلبه التطبيق من SQL Server، وقمت ببعض التفكير فيه (التطبيق عبارة عن موقع ويب .NET 1.1) ويستخدم الحقل المخالف لبعض الأشياء الداخلية التي ليس لدي أي فكرة عنها ما هو عليه.

أحتاج إلى تحسين الأداء العام لهذا الجدول.

Answer 1

أنصحك بالنظر في صحة تخطيط الجدول المخالف:

select * from sys.dm_db_index_physical_stats(
       db_id(), object_id('offending_table'), null, null, detailed);

الأشياء التي تبحث عنها أيضًا هي avg_fragmentation_in_percent، وpage_count، وavg_page_space_used_in_percent، وrecord_count، وghost_record_count.تشير الإشارات مثل التجزئة العالية، أو العدد الكبير من سجلات الأشباح، أو النسبة المئوية المنخفضة للصفحة المستخدمة إلى وجود مشكلات ويمكن تحسين الأمور قليلاً فقط عن طريق إعادة بناء الفهرس (على سبيل المثال.الجدول) من الصفر:

ALTER INDEX ALL ON offending_table REBUILD;

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

سأبحث أيضًا في متوسط ​​عمر الصفحة في عدادات الأداء لفهم ما إذا كان النظام يعاني من نقص الذاكرة.من وصفك للأعراض، يبدو النظام مرتبطًا بـ IO مما يقودني إلى الاعتقاد بوجود القليل من التخزين المؤقت للصفحات، ويمكن أن يساعد المزيد من ذاكرة الوصول العشوائي (RAM)، بالإضافة إلى نظام فرعي IO أسرع.في نظام SQL 2008، أود أيضًا أن أقترح تشغيل ضغط الصفحات، لكن في عام 2005 لا يمكنك ذلك.
وللتأكد فقط، تأكد من عدم حظر الاستعلامات عن طريق التنافس من التطبيق نفسه، أي.لا يقضي الاستعلام 90% من هذه الـ 30 ثانية في انتظار قفل الصف.ينظر الى sys.dm_exec_requests أثناء تشغيل الاستعلام، راجع wait_time وwait_type وwait_resource.هل هي PAGEIOLATCH_XX؟أم أنه قفل؟وأيضا كيف الحال sys.dm_os_wait_stats في الخادم الخاص بك، ما هي أهم أسباب الانتظار؟

Answer 2

أولاً - لا تفعل أي وقت مضى SELECT * في رمز الإنتاج - الإبلاغ أم لا.

لديك ثلاثة خيارات أساسية:

• انقل حقل blob هذا إلى جدول منفصل إذا لم تكن هناك حاجة إليه دائمًا؛ربما ليس عمليًا لأنك ذكرت أنه لا يمكنك تغيير المخطط

• كن أكثر حذرا مع الخاص بك SELECT عبارات لتحديد تلك الحقول التي تحتاجها حقًا فقط - وحذف حقل blob

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

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

إن مجرد تغيير الحقل إلى VARBINARY(MAX) لن يغير أي شيء على الإطلاق - لا يتوقع حدوث تحسن في الأداء بمجرد تغيير نوع البيانات.

Answer 3

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

Answer 4

من المؤكد أن تعيين خيار أنواع القيمة الكبيرة خارج الصف يجب أن يساعد في الأداء.سيكون حجم الصف أصغر بكثير، ويمكن لـ SQL Server إجراء عدد أقل بكثير من عمليات القراءة الفعلية لتصفح الجدول.