ראשית, אין בעד מה וכמו שאמרתי לך, זאת לא שאילתה יעילה במיוחד וככל שהנתונים ילכו ויצטברו, כך ייקח לה יותר זמן לחזור.כמו כן אני מציין מראש שב-MYSQL אני פחות מבין () אבל יכול לתת המלצות.
נתחיל מ-filesort:
אם הוא מבצע את ה-filesort אחרי שכבר חזרו כל הנתונים (ז"א רק בגלל ה-order by) אז לא צריך להיות לך אכפת, זאת פעולה זולה.
אם הוא מבצע את ה-filesort לפני ה-join אז זה משפר לך את הביצועים, כי תחשוב שביצעת פעולה אחת כבדה (ו-filesort לא כזה כבד) ועכשיו הטבלה מסודרת ובמקום עבור כל רשומה לרוץ על כל הטבלה, אתה יכול לגשת מהר מאד לחיתוכים המתאימים.
הבעיה היא שאם אין אינדקסים על הטבלה, זה מאלץ את האופטימייזר של השליפה לבצע filesort, שזאת פעולה יחסית כבדה על טבלה גדולה. אם נשתמש באינדקסים על itemid לבדו, ייתכן שהוא לא יבצע filesort (ואם כן, אז הוא לא אמור לבצע על כל הטבלה) ואם תוסיף אינדקס גם עם ה-itemtype (שזה פחות קריטי לדעתי), הוא לא אמור לבצע filesort בכלל, אבל אמור לפעמים זה שם של דג.
בסופו של דבר הכל שיקולים של קריאה וכתיבה וככל שיש יותר אינדקסים, כך הכתיבה איטית יותר.
מכיוון שמדובר בטבלה יחסית קטנה, אין שום בעולם שבתור התחלה לא תשים אינדקס (ואפילו PRIMARY KEY) על itemid ותראה איך זה משפיע. אני לא חושב שיש צורך לשים גם על itemtype כי כאשר יהיה לך אינדקס על itemid, תוכל מהר מאד להצלבה בין הטבלאות והבדיקה של ה-itemtype היא מהירה מאד.
בנוסף אני ממליץ (וזה נכון באופן כללי) לחלק את הטבלה למחיצות לפי תאריכים, כי אם למשל אתה יודע שהנתונים של חודש אחורה לא מעניינים אותך ויש לך מחיצות לפי חודשים ותשלוף חודש אחורה, תוכל לחתוך מהר מאד חלק גדול מהטבלה.
תעדכן אותי לגבי הביצועים, זה תמיד מעניין