בוקר טוב
לא עברתי על כל השרשור לעומק אז אני מתנצל מראש אם אני חוזר על משהו שנאמר אבל נראה לי שלא דנתם בדבר הבא וזה יכול לעזור פלאים
תחילה הייתי מבודד לחלוטין את החלק הבא בשאילתה עד לסיום המיטוב שלו:
select t1.id
as PKid,t2.id
as IndexId
FROM TargetTable t1
inner
join Dyn_Content t2
(NOLOCK)
ON t1.[Content]=t2.Value
COLLATE SQL_Latin1_General_CP1_CI_AS
עתה נעבוד רק על חלק זה בלבד: הבעיה כפי הנראה היא בכך שמבוצע כרגע
Index Scan במקום
Index Seek. 90% מהמשאבים הולכים על סריקת הטבלה.
אם אני מבין נכון הרי ששדה
t1.[Content] ושדה
t2.Value הם שדות טקסטואליים גדולים ולכן מבוצע סריקה בצורה זו. אחת השיטות לעקוף את
הבעיה היא להוסיף שדה מיוחד רק עבור אינדקס שמייצג נכונה את ההטקסט של שדות אלו (בתכנות נעזרים במה שנקרא פונקצית
HASH = פונקציה שמגדירה קשר בין מפתח לבין הערכים ואז ניתן לבצע מיון לפי המפתח בצורה מהירה)
אחד הפתרונות לעבודה עם טקסט גדול זה שימוש ב
full test search. לכן המלצה ראשונה היא לחשוב/לנסות ביצוע החיבור בין הטבלאות באמצעות השוואה בדרך זו.
הדרך השנייה נקראת Hash indexes ועליה דיברתי מעל. הרעיון הוא ליצור שדה
מחושב נוסף בטבלה שיחושב מהשדות הטקסטואליים ועל שדה זה נוכל להקים אינדקס פשוט. את השוואת הנתונים נוכל לבצע על שדה זה כמובן כי הוא מוסס על השדה הטסטואלי שלנו ורק אז נבצע סינון משני בתוצאה הסופית לבדוק שאכן לא קיבלנו בטעות כמה ערכים (פונקציית ההאש שלנו היתה אידאלית
אם היתה נותנת יחס של 1:1 בין המקור לשדה המחושב אבל בדרך כלל היחס הוא יחיד לרבים... ז"א יכול להיות מצב תיאורטית אם כי הסיכוי נמוך במקרה של שימוש ב CHECKSUM שכמה טקסטים יקבלו אותו ערך מחושב)
הדוגמה הכי פשוט היא יצירת שדה
CHECKSUM על השדה הטקסטואלי שלנו.
ALTER
TABLE MyTbl
ADD cs_Txt
AS CHECKSUM(Txt);
GO
CREATE
INDEX cs_Txt_index ON MyTbl
(cs_Txt);
GO
* ניתן כמובן לבחור בפונקצית
HASHאחרת על מנת להגדיר את הקשר בין המפתח החדש שונים ובין הטקסט הקיים. עתה כשתבצע שימוש בטבלה תוכל לעשות שימוש בשדה אינדקס זה ולא תיה סריקה של כל הטבלה
