هل تتم فهرسة المفاتيح الخارجية تلقائيًا في SQL Server؟

Question

هل ستقوم عبارة SQL التالية تلقائيًا بإنشاء فهرس على Table1.Table1Column، أم يجب إنشاء فهرس بشكل صريح؟

محرك قاعدة البيانات هو SQL Server 2000

       CREATE TABLE [Table1] (
. . .
            CONSTRAINT [FK_Table1_Table2] FOREIGN KEY 
            (
                [Table1Column]
            ) REFERENCES [Table2] (
                [Table2ID]
            )

        )

Answer 1

سوف

وSQL Server لا تلقائيا إنشاء فهرس على المفتاح الخارجي. أيضا من MSDN:

<اقتباس فقرة>   

لايوجد قيد مفتاح خارجي   أن تكون مرتبطة فقط لمفتاح أساسي   القيد في جدول آخر. يمكن   أيضا تعريف مرجع   أعمدة قيد UNIQUE في   جدول آخر. مفتاح خارجي   يمكن أن تحتوي القيد القيم الخالية.   ومع ذلك، إذا أي عمود من مركب   قيد FOREIGN KEY يحتوي على باطل   القيم، والتحقق من كل القيم   التي تشكل المفتاح الخارجي   يتم تخطي عقبة. للتأكد من   أن جميع القيم من FOREIGN المركبة   يتم التحقق من قيد مفتاح، حدد   NOT NULL على جميع المشاركين   الأعمدة.

Answer 2

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

و(تحرير: أضيفت للتعامل بشكل واضح مع التعليق أدناه -) على وجه التحديد، عند تقديم اتساق البيانات التي قيد مفتاح خارجي هناك ل. مؤشر يمكن أن تؤثر على أداء DRI القيد فقط للحذف من الصف أو الصفوف على الجانب FK. عند استخدام القيد، وذلك خلال إدراج أو تحديث المعالج يعرف قيمة FK، ويجب أن تحقق من وجود صف في الجدول المشار إليه على الجانب PK. بالفعل هناك مؤشر هناك. عند حذف صف واحد على الجانب PK، يجب أن تحقق من وجود أية صفوف على الجانب FK. مؤشر يمكن أن تكون مفيدة بشكل هامشي في هذه الحالة. ولكن هذا ليس سيناريو شائع.

وبخلاف ذلك، في أنواع معينة من الأسئلة، ومع ذلك، حيث يحتاج معالج الاستعلام للبحث عن السجلات على الجانب العديد من الانضمام الذي يستخدم هذا العمود المفتاح الخارجي. انضمام الأداء <م> هو زيادة عند وجود مؤشر على أن المفتاح الخارجي. ولكن هذا الشرط هو غريبة لاستخدام عمود FK في الانضمام الاستعلام، وليس لوجود قيد المفتاح الخارجي ... لا يهم ما إذا كان الجانب الآخر من الانضمام هو PK أو بعض الأعمدة تعسفي آخر. أيضا، إذا كنت بحاجة لتصفية، أو تأمر نتائج استعلام يستند هذا العمود FK، ومؤشر يساعد ... مرة أخرى، وهذا لا علاقة له قيد المفتاح الخارجي في هذا العمود لا شيء.

Answer 3

لا، إن إنشاء مفتاح خارجي في عمود لا يؤدي تلقائيًا إلى إنشاء فهرس في هذا العمود.سيؤدي الفشل في فهرسة عمود المفتاح الخارجي إلى فحص الجدول في كل من الحالات التالية:

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

في هذا المخطط المثال:

CREATE TABLE MasterOrder (
   MasterOrderID INT PRIMARY KEY)

CREATE TABLE OrderDetail(
   OrderDetailID INT,
   MasterOrderID INT  FOREIGN KEY REFERENCES MasterOrder(MasterOrderID)
)

سيتم فحص OrderDetail في كل مرة يتم فيها حذف سجل في جدول MasterOrder.سيتم أيضًا فحص جدول OrderDetail بأكمله في كل مرة تنضم فيها إلى OrderMaster وOrderDetail.

   SELECT ..
   FROM 
      MasterOrder ord
      LEFT JOIN OrderDetail det
       ON det.MasterOrderID = ord.MasterOrderID
   WHERE ord.OrderMasterID = @OrderMasterID

بشكل عام، يعد عدم فهرسة المفتاح الخارجي بمثابة الاستثناء أكثر من القاعدة.

حالة عدم فهرسة المفتاح الخارجي هي حيث لن يتم استخدامه أبدًا.وهذا من شأنه أن يجعل الحمل الزائد على الخادم لصيانته غير ضروري.قد تندرج جداول الكتابة ضمن هذه الفئة من وقت لآخر، على سبيل المثال قد يكون:

CREATE TABLE CarType (
   CarTypeID INT PRIMARY KEY,
   CarTypeName VARCHAR(25)
)

INSERT CarType .. VALUES(1,'SEDAN')
INSERT CarType .. VALUES(2,'COUP')
INSERT CarType .. VALUES(3,'CONVERTABLE')

CREATE TABLE CarInventory (
   CarInventoryID INT,
   CarTypeID INT  FOREIGN KEY REFERENCES CarType(CarTypeID)
)

إذا افترضنا الافتراض العام بأن الحقل CarType.CarTypeID لن يتم تحديثه أبدًا وأن حذف السجلات لن يتم على الإطلاق تقريبًا، فإن الحمل الزائد للخادم للحفاظ على فهرس في CarInventory.CarTypeID سيكون غير ضروري إذا لم يتم البحث في CarInventory مطلقًا بواسطة CarTypeID.