Query optimizer foloseste pentru aflarea planurilor de executie optime informatiile despre schema (obiectele din baza de date) si statisticile.
Stie cineva daca "foreign key constraint"-urile sunt folosite de optimizor pentru un statement de tip SELECT? Ati gasit chestia asta documetata pe undeva?
Multumesc.

---

Florin Cardasim

In ce sens sa fie folosite pt. optimizare? foreign key-urile nu contin informatii despre ce anume se gaseste in paginile fizice pe disk, doar indexii si statisticile contin astfel de informatii. Un foreign key e doar un constraint (o formula) care se aplica la insert, update, delete).

In principiu trebuie sa creezi un index pe coloanele unui foreign key, pt. ca query engine-ul sa optimize select-urile cu join care se fac intre 2 tabele chiar daca join-ul se face folosind coloanele pentru care exista un foreign key definit.

In plus creerea unui index pe coloanele unui foreign key din tabela child, ajuta la performata in cazul verificarilor care se fac cand se executa delete (sau update pe PK) pe tabela parinte.

Este ceva aici : http://sqlblog.com/blogs/tibor_karaszi/archive/2008/01/12/non-trusted-constraints.aspx
http://sqlblog.com/blogs/tibor_karaszi/archive/2008/01/12/non-trusted-constraints-and-performance.aspx

---

Gheorghe Ciubuc,SQL Server Influencer, MCP(SQL 2000), MCTS (SQL Server 2005) , OCA(Oracle 9i), Sybase(Brainbench)

Da, foreign key-urile pot fi folosite de Query Optimizer pentru a genera un plan de execuţie mai bun pentru instrucţiunile de tip SELECT. De exemplu, rulaţi următorul script (în SQL Server 2005), cu opţiunea "Include Actual Execution Plan":

CREATE TABLE T1 (X INT PRIMARY KEY)
CREATE TABLE T2 (Y INT PRIMARY KEY, X INT NOT NULL)

INSERT INTO T1 VALUES (1)
INSERT INTO T1 VALUES (2)
INSERT INTO T1 VALUES (3)

INSERT INTO T2 VALUES (100, 1)
INSERT INTO T2 VALUES (101, 1)
INSERT INTO T2 VALUES (102, 2)

SELECT COUNT(*) FROM T1 INNER JOIN T2 ON T1.X=T2.X

ALTER TABLE T2 ADD FOREIGN KEY (X) REFERENCES T1(X)

SELECT COUNT(*) FROM T1 INNER JOIN T2 ON T1.X=T2.X

DROP TABLE T2,T1

Se observă că pentru al doilea SELECT (deşi acesta este identic cu primul SELECT), query plan-ul este mai simplu (mai eficient). Asta deoarece query optimizer-ul şi-a dat seama că în condiţiile în care există acest constraint, query-ul respectiv devine echivalent cu query-ul "SELECT COUNT(*) FROM T2" şi nu a mai accesat deloc tabela T1.

Răzvan

Răzvan, asta nu se intampla daca nu exista foreign key?

Edit: mie mi-au iesit rezultate identice cu sau fara FK de fiecare data

Cred că nu ai obţinut rezultatele aşteptate din cauza unei opţiuni a bazei de date. La mine, obţin rezultatele dorite dacă rulez script-ul în master, dar obţin acelaşi execution plan la ambele query-uri dacă rulez script-ul în tempdb. Încă nu mi-am dat seama care este opţiunea care influenţează acest lucru; voi mai studia problema astă seară.

Răzvan

La prima vedere pe SQL2000DEV, SQL2005DEV si SQL2008RTM rezultatele sunt asemanatoare la modul: in tempdb planurile sunt asemanatoare, dar in master si o baza de date utilizator planurile sunt intr-adevar diferite.

Multumesc!

---

Florin Cardasim