الحذف
بخلاف عبارة insert، تمتلك عبارة delete جملة where يمكنها استخدام جميع الأساليب الموصوفة في الفصل 2، «جملة WHERE»، للاستفادة مباشرة من الفهارس. بل إن عبارة delete تعمل مثل select تتبعها خطوة إضافية لحذف الصفوف المحدَّدة.
الحذف الفعلي لصف عملية شبيهة بإدراج صف جديد — ولا سيما إزالة المراجع من الفهارس والأنشطة اللازمة للحفاظ على توازن أشجار الفهارس. ولذلك فإن مخطط الأداء المعروض في الشكل 8.2 شبيه جداً بالمخطط المعروض من أجل insert.
الشكل 8.2 أداء الحذف حسب عدد الفهارس
من الناحية النظرية، نتوقع أفضل أداء حذف لجدول بلا أي فهارس — كما هو الحال مع insert. غير أنه إذا لم يوجد أي فهرس، وجب على قاعدة البيانات قراءة الجدول بالكامل للعثور على الصفوف المراد حذفها. ويعني ذلك أن حذف الصف سيكون سريعاً، لكن العثور عليه سيكون بطيئاً جداً. ولهذا لا تظهر هذه الحالة في الشكل 8.2.
ومع ذلك، قد يكون من المعقول تنفيذ عبارة delete دون فهرس، تماماً كما قد يكون من المعقول تنفيذ عبارة select دون فهرس إذا كانت تُرجع جزءاً كبيراً من الجدول.
نصيحة
حتى عبارات delete وupdate لها خطة تنفيذ (execution plan).
تُعدّ عبارة delete بلا جملة where مثالاً واضحاً لا تستطيع فيه قاعدة البيانات استخدام فهرس، مع أن هذه حالة خاصة لها أمر SQL خاص بها: truncate table. ولهذا الأمر الأثر نفسه الذي لـdelete بلا where، إلا أنه يحذف جميع الصفوف دفعة واحدة. وهو سريع جداً لكن له تأثيران جانبيان مهمان: (1) ينفّذ إيداعاً ضمنياً (commit) (الاستثناءات: PostgreSQL وSQL Server)؛ (2) لا ينفّذ أي مُشغِّلات (triggers).
الآثار الجانبية للتحكم بالتزامن متعدد الإصدارات (MVCC)
التحكم بالتزامن متعدد الإصدارات (multiversion concurrency control — MVCC) آلية في قاعدة البيانات تُتيح وصولاً متزامناً غير حاجب إلى البيانات ورؤية متسقة للمعاملات (transactions). غير أن تطبيقاته تختلف من قاعدة بيانات إلى أخرى، وقد تكون لها حتى آثار كبيرة على الأداء.
تحتفظ قاعدة بيانات PostgreSQL، على سبيل المثال، بمعلومات الإصدار (=معلومات الظهور) على مستوى الجدول فقط: فحذف صف يقتصر على ضبط راية «محذوف» في كتلة الجدول. ولهذا فإن أداء الحذف في PostgreSQL لا يعتمد على عدد الفهارس على الجدول. ولا يُنفَّذ الحذف الفيزيائي لصف الجدول وما يرتبط به من صيانة الفهرس (index maintenance) إلا أثناء عملية VACUUM.