איך עושים JOIN?

[nigun]

@OdedDvir אמר באיך עושים JOIN?:

@nigun אמר באיך עושים JOIN?:

אולי אני ישאיר את זה לחצי שעה

אני עדיין מציע לך לבצע סינון WHERE לפי הקבוצה לפני הJOIN, ולהרוויח את הזמן הזה:

SELECT P.user, P.points,I.nameText
FROM (SELECT * FROM points WHERE points.grup=123) AS P
JOIN (SELECT * FROM userinfo WHERE userinfo.grup=123) AS I
ON P.user=I.user; 

יפה
עכשיו זה ירד ל0.23 שניות.

[dovid]

בדרך כלל המסד נתונים לבד בוחר לבצע סינון לפני הJOIN אם יש לו אינדיקציות ברורות שזה שווה.

[nigun]

@dovid
אז מה השתבש אצלי?

[dovid]

@nigun זה מה שאני שואל את עצמי לאורך כל האשכול.

[OdedDvir]

@nigun אמר באיך עושים JOIN?:

מעניין מה ההבדל?

כתבתי למעלה, שמשום מה סדר הריצה של המסד נתונים שלך היה קודם כל לבצע JOIN (מה שיצר כנראה מליוני רשומות) ורק אח"כ סינון ב-WHERE.
תוסיף את העניין שמדובר ב-JOIN של מחרוזות שגם הוא איטי בהרבה מJOIN של מספרים - וקיבלת חצי שעה של תעסוקה למעבד...

@dovid אמר באיך עושים JOIN?:

בדרך כלל המסד נתונים לבד בוחר לבצע סינון לפני הJOIN אם יש לו אינדיקציות ברורות שזה שווה.

אולי עדיף לא להשאיר את הדבר בידיים של הDB איפה שאפשר בקלות לקבוע את הסדר כדלעיל?

[nigun]

בהמשך לשאלה הנ"ל
לפעמים יש משתמשים שלא רשומים ב userinfo
אבל אני בכל זאת אני רוצה לקבל את הרשומה שלהם בpoints
איך אני כותב את השאילתא?

[OdedDvir]

@nigun בעיקרון אתה כותב LEFT JOIN במקום JOIN

[dovid]

LEFT JOIN זה למקרה שאתה רוצה את כל השורות של הטבלה שצויינה ראשונה (שזה לשמאל הביטוי JOIN). למקרה הפוך יש RIGHT JOIN. הברירת מחדל היא INNER שזה רק הזהים, ויש את FULL שזה הכל משני הצדדים. בחלק ממסדי הנתונים האחרון לא נתמך.

[dovid]

@OdedDvir אמר באיך עושים JOIN?:

אולי עדיף לא להשאיר את הדבר בידיים של הDB איפה שאפשר בקלות לקבוע את הסדר כדלעיל?

זה לגיטימי לעיתים נדירות, אחרת הרסת את כל הרעיון של SQL ("תגיד מה אתה רוצה, אני אדאג לאיך").
מקרה שבו הDB כ"כ מזייף הוא משונה מאוד. ב99% מהמקרים הDB חכם מספיק לעשות את הסדר הכי טוב.

[OdedDvir]

@dovid אמר באיך עושים JOIN?:

זה לגיטימי לעיתים נדירות, אחרת הרסת את כל הרעיון של SQL ("תגיד מה אתה רוצה, אני אדאג לאיך").

אני עדיין אוחז ב"תגיד מה אתה רוצה ועדיין תדאג"...

מקרה שבו הDB כ"כ מזייף הוא משונה מאוד. ב99% מהמקרים הDB חכם מספיק לעשות את הסדר הכי טוב.

מעניין לראות את תוכנית הריצה של השאילתא הארוכה. אם @nigun יוכל להראות אותה כאן (כמובן רק אם זה לא ידרוש שוב חצי שעה...)

[dovid]

@OdedDvir אמר באיך עושים JOIN?:

@dovid אמר באיך עושים JOIN?:

זה לגיטימי לעיתים נדירות, אחרת הרסת את כל הרעיון של SQL ("תגיד מה אתה רוצה, אני אדאג לאיך").

אני עדיין אוחז ב"תגיד מה אתה רוצה ועדיין תדאג"...

זה לא נורמלי, במקרים רגילים אמורים להיות רגועים לחלוטין.
מצב בו חושבים מה יותר יעיל בכל שאילתה אינו הגיוני כי SQL מסתיר המון מידע, פרטים פיזיים וטכניים שקריטיים לאיך לבצע את השאילתה. כל עוד הוא אחראי אתה סומך על ידיעותיו, אבל אם אתה נהיה "אחראי" למיטוב השאילתות, אתה מגשש באפילה עם סברות שלא תמיד בקנה אחד עם המצב הטכני של הנתונים.

[OdedDvir]

@dovid אמר באיך עושים JOIN?:

זה לא נורמלי, במקרים רגילים אמורים להיות רגועים לחלוטין.

אני משער שכך הוא בבסיסי נתונים מקצועיים.
לצערי אני מגיע משדה הקרב של Access, שם Jet לא מגיע לרמות של אופטימיזציה כזו, נוכחתי לדעת ששאילתא שלקחה לי למעלה מ-4 דקות עם הרבה Join-ים הפכה ל-3 שניות כשסידרתי אותה מחדש (עם טבלאות זמניות וכו').

נו, עוד מסמר בארון של אקסס...

[dovid]

@OdedDvir אני חושב שגם אקסס הוא בסדר יחסית. אתה מדבר על שאילות רציניות מאוד, והראיה שאתה מזכיר טבלאות זמניות.

[OdedDvir]

@dovid אמר באיך עושים JOIN?:

אתה מדבר על שאילות רציניות מאוד

נכון, היו שם לפחות 20 Join-ים של שאילתות שונות.
לפי זכרוני עיקר הבעיה שם הייתה שהייתה שאילתא מאוד בסיסית שעושה סינון על טבלה (כדי לשלוף רק את הנתונים הרלוונטיים למערכת) והרבה מהשאילתות הנ"ל התבססו עליה (כדי לחשב כל אחת את הדרוש לה) ואח"כ בוצע Join. זה גרם קריאות רבות לאותה שאילתא, והפתרון היה טבלת עזר זמנית.

[nigun]

@OdedDvir אמר באיך עושים JOIN?:

מקרה שבו הDB כ"כ מזייף הוא משונה מאוד. ב99% מהמקרים הDB חכם מספיק לעשות את הסדר הכי טוב.

מעניין לראות את תוכנית הריצה של השאילתא הארוכה. אם @nigun יוכל להראות אותה כאן (כמובן רק אם זה לא ידרוש שוב חצי שעה...)

לא אכפת לי להעסיק את המכונה שלי לעוד חצי שעה (תופס סך הכל ליבה אחת)
אבל אני לא יודע איך מציגים את התוכנית ריצה?

[OdedDvir]

@nigun התחביר הוא:

EXPLAIN ANALYZE <SQL>

כלומר:

EXPLAIN ANALYZE SELECT points.user, points.points FROM points JOIN info ON info.user=points.user

[nigun]

@OdedDvir
נראה שזה לא זמין בגירסת MYSQL שלי
אז עשיתי EXPLAIN EXTENDED

+----+-------------+----------+------+---------------+------+---------+------+--------+----------+----------------------------------------------------+
| id | select_type | table    | type | possible_keys | key  | key_len | ref  | rows   | filtered | Extra                                              |
+----+-------------+----------+------+---------------+------+---------+------+--------+----------+----------------------------------------------------+
|  1 | SIMPLE      | userinfo | ALL  | NULL          | NULL | NULL    | NULL |  30410 |   100.00 | NULL                                               |
|  1 | SIMPLE      | points   | ALL  | NULL          | NULL | NULL    | NULL | 359834 |   100.00 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+----------+------+---------------+------+---------+------+--------+----------+----------------------------------------------------+

[OdedDvir]

@nigun איזו גירסא יש לך?

[nigun]

@OdedDvir
mysql 5.6.49

[dovid]

@nigun הסתקרנתי פתאום יותר אז עליתי לראות את מבנה הנתונים.
הוא לא היה קריא (ולכן עזבתי בפעמים הקודמות שביקרתי את הנושא, בלי לבדוק...)
ערכתי את הודעתך ועיצבתי את הקוד.
ובכן, השאלה שמייד עולה זה למה לעשות JOIN בין שני עמודות שאינם שדה מפתח. למה השדה user בpoints לא מצביע על הid של שבטבלה userinfo? (ואיך זה שאורכי השדות של הvarchar בשני שדות הuser לא זהים, זה לא כ"כ הגיוני).

אגב גירסת הmysql: בכל אובנטו מתקינים בד"כ mysql כמו ילדים טובים מהמנהל חבילות ונתקעים עם הגירסה המיושנת 5 (אוחזים כעת ב12!!). לתשומת לבכם בהתקנת השרת הבאה שלכם. לגירסה 12 יש המון פיצ'רים שאין ב5.