תארו לעצמכם: עמוד קטלוג עם פילטר נטען תוך 7 שניות. משתמשים עוזבים, ההמרה יורדת. EXPLAIN מציג 15 JOIN לטבלת המאפיינים — ביטריקס קלאסית עם גידול בנתונים. המצב הזה מוכר לכל מי שעובד עם קטלוגים של ביטריקס. למדנו לאתר צווארי בקבוק ולחסל אותם ללא סיכון לפונקציונליות. הצוות שלנו עוזר לעשרות פרויקטים להאיץ בחירות פי 5–20 ללא שינוי בפלטפורמה. במהלך השנים האחרונות, ביצענו יותר מ-200 אופטימיזציות, וב-80% מהמקרים, הגורם השורשי הוא אינדקסים שגויים ו-JOIN מיותרים. בואו נפרק איך לתקן את זה, כדי שתוכלו לחסוך במשאבי שרת ולהאיץ את מהירות הקטלוג ל-100 אלפיות השנייה.
צרו קשר לבדיקה חינמית של הקטלוג שלכם — הערכת שאילתות JOIN והמלצות.
איך ביטריקס בונה שאילתות JOIN
העברת מאפיינים ב-$arSelectFields או סינון לפיהם גורמת לביטריקס להוסיף JOIN למספר טבלאות בהתאם לסוג אחסון המאפיינים:
- מאפיינים רגילים —
LEFT JOIN b_iblock_element_property AS p1 ON p1.IBLOCK_ELEMENT_ID = be.ID AND p1.IBLOCK_PROPERTY_ID = N - מאפיינים מרובי ערכים — כל ערך כשורה נפרדת ב-
b_iblock_element_property, JOIN מחזיר מספר שורות לכל פריט - מאפייני UTS — טבלה נפרדת
b_uts_iblock_N_singleאוb_uts_iblock_N_multiple, JOIN עלIBLOCK_ELEMENT_ID - מאפיין רשימה — JOIN נוסף ל-
b_iblock_property_enum
הבעיה: אם אתם מבקשים 10 מאפיינים עבור 1000 פריטים, ביטריקס בונה שאילתה עם 10+ JOIN. MySQL מבצע לולאות מקוננות — עבור כל שורה מטבלה אחת, הוא עובר על הטבלה המקושרת. ללא אינדקסים על מפתחות JOIN, מדובר בסריקה מלאה בכל איטרציה. מידע נוסף ב-SQL JOIN.
שלוש סיבות עיקריות לשאילתות JOIN איטיות
אינדקסים חסרים על עמודות JOIN
המקרה הנפוץ ביותר — JOIN על IBLOCK_ELEMENT_ID ב-b_iblock_element_property ללא אינדקס מתאים. ביטריקס יוצרת אינדקס ix1 על (IBLOCK_ELEMENT_ID) במהלך ההתקנה, אך עם גידול בנתונים זה לא מספיק. EXPLAIN יציג type=ALL על טבלת המאפיינים.
בדקו אינדקסים:
SHOW INDEX FROM b_iblock_element_property; SHOW INDEX FROM b_uts_iblock_5_single; -- для инфоблока ID 5 עבור טבלאות UTS, אינדקסים לא נוצרים אוטומטית בעת הוספת מאפיינים דרך ממשק הניהול.
JOIN על שדה מחרוזת VALUE עם נתונים מספריים
השדה SHOW INDEX FROM b_iblock_element_property; SHOW INDEX FROM b_uts_iblock_5_single; -- для инфоблока ID 5 ב-VALUE הוא מסוג b_iblock_element_property או TEXT. סינון VARCHAR(255) הוא השוואת מחרוזות; אינדקס על שדה TEXT אינו יעיל, והמרת טיפוסים ב-JOIN שוברת את השימוש באינדקס. עבור מאפיינים עם ערכים מספריים, ביטריקס משכפלת נתונים בשדה WHERE p.VALUE = '100' (FLOAT) — השתמשו בו.
שאילתת מספר מאפיינים ב-JOIN יחיד
שליפת 5 מאפיינים מרובי ערכים משכפלת שורות: אם לפריט יש 3 ערכים עבור מאפיין A ו-4 עבור מאפיין B, השאילתה מחזירה 12 שורות לכל פריט. MySQL מעבד מכפלה קרטזית, ואז מבצע קיבוץ. עבור 10,000 פריטים, התוצאה הביניים יכולה להיות מיליוני שורות.
אופטימיזציה: פיצול לשתי שאילתות — קודם קבלו את הנתונים הראשיים, ואז טענו ערכי מאפיינים מרובי ערכים בנפרד עם מערך של מזהים.
מתי להעביר מאפיינים ל-HL-Blocks?
HL-blocks מאחסנים נתונים בטבלה נפרדת ללא JOIN ל-VALUE_NUM. אם מאפיין נמצא בשימוש פעיל בפילטרים, יש לו מיליוני ערכים, או דורש מיון מורכב — זהו אות להעברה. לדוגמה, עבור מאפיינים טכניים (משקל, גובה), HL-block מספק שיפור ביצועים של עד פי 10 בבחירות מסוננות. אין צורך לשנות את לוגיקת הקטלוג: פשוט הגדירו קישור דרך שדה b_iblock_element_property. ריפקטורינג עם D7 ORM מאיץ שאילתות פי 10 בהשוואה ל-GetList הסטנדרטי, ו-HL-blocks נותנים עד פי 20 שיפור בפילטרים.
איך לאבחן עם EXPLAIN
אנו משתמשים ב-EXPLAIN עבור כל שאילתה איטית. שימו לב לעמודת UF_PRODUCT_ID: אם אתם רואים type (סריקה מלאה) או ALL (סריקת אינדקס), חפשו להוסיף אינדקס או לשכתב את השאילתה. ערכים אופטימליים הם index או ref.
דוגמת EXPLAIN
```sql EXPLAIN SELECT be.ID, be.NAME, p.VALUE FROM b_iblock_element be INNER JOIN b_iblock_element_property p ON p.IBLOCK_ELEMENT_ID = be.ID AND p.IBLOCK_PROPERTY_ID = 42 WHERE be.IBLOCK_ID = 5 AND be.ACTIVE = 'Y' ORDER BY be.SORT LIMIT 20; ```איך אנחנו מבצעים אופטימיזציה: תהליך שלב-אחר-שלב
- ניתוח EXPLAIN — איתור שאילתות איטיות, זיהוי אינדקסים חסרים.
- הוספת אינדקסים — יצירת אינדקסים מורכבים עבור שדות JOIN וסינון.
- ריפקטורינג לבחירת מאפיינים — פיצול שאילתות עם מאפיינים מרובים, החלפת LEFT JOIN ב-EXISTS.
- מעבר ל-D7 ORM — עבור קטעים קריטיים, שימוש ב-D7 ORM עם קשרים מפורשים.
- בדיקות — מדידת זמן ביצוע לפני ואחרי, תיעוד תוצאות.
D7 ORM: הדרך המודרנית להילחם ב-JOIN
D7 ORM מאפשר לשלוט אילו טבלאות נכללות ב-JOIN דרך פרמטר eq_ref וקשרים מפורשים. בעבודה עם HL-blocks, D7 מייצר שאילתות נקיות יותר ללא JOIN מיותרים ל-runtime. השוואה: GetList סטנדרטי עבור 10 מאפיינים — 10 JOIN; D7 ORM עם HL-block — 0 JOIN עבור 10,000 פריטים.
// Избегаем JOIN к таблице свойств, работаем напрямую с HL-таблицей
$result = \Bitrix\Highloadblock\HighloadBlockTable::compileEntity($hlBlock)
->getDataClass()::getList([
'select' => ['ID', 'UF_PRODUCT_ID', 'UF_PRICE'],
'filter' => ['>=UF_PRICE' => 1000, '<=UF_PRICE' => 5000],
'limit' => 100,
]);
מידע נוסף ב-תיעוד D7 ORM.
השוואת גישות לאחסון מאפיינים
| אחסון | JOIN ל-b_iblock_element_property | ביצועים ב-1M פריטים | אינדוקס |
|---|---|---|---|
| מאפיינים סטנדרטיים | כן, מספר JOIN | נמוך (2–5 שניות לשאילתה) | רק לפי IBLOCK_ELEMENT_ID |
| טבלת UTS | כן, JOIN אחד | בינוני (0.5–2 שניות) | מותאם אישית אפשרי |
| HL-block | לא | גבוה (10–50 אלפיות השנייה) | אינדוקס גמיש |
תהליך ולוחות זמנים
| משימה | לוח זמנים | השפעה |
|---|---|---|
| ניתוח EXPLAIN של JOIN, הוספת אינדקסים | 2–3 ימים | האצה פי 5–20 בשאילתות בעייתיות |
| ריפקטורינג לבחירת מאפיינים (פיצול תת-שאילתות) | 3–5 ימים | ביטול מכפלה קרטזית |
| העברת מאפיינים בשימוש כבד ל-HL-blocks | 1–2 שבועות | ביטול JOIN ל-b_iblock_element_property |
| אופטימיזציה מקיפה של הקטלוג | 2–3 שבועות | עמוד קטלוג < 100 אלפיות השנייה במקום 2–5 שניות |
התמחור מחושב באופן אישי. צרו קשר לבדיקה חינמית — נעריך את ההיקף ונספק לוחות זמנים ראשוניים.
מה כלול
- ביקורת על שאילתות ואינדקסים קיימים (EXPLAIN, ניתוח פרופיל שרת)
- הוספה ואופטימיזציה של אינדקסים על שדות מפתח
- ריפקטורינג לבחירת מאפיינים (פיצול JOIN מרובים, החלפה בתת-שאילתות)
- העברת מאפיינים בשימוש כבד ל-HL-blocks עם העברת נתונים
- תיעוד שינויים והמלצות תחזוקה
- הדרכת הצוות שלכם על D7 ORM והגדרת מטמון
- תמיכה ותחזוקה לאחר הפרויקט
למה לסמוך עלינו?
מעל 10 שנות פיתוח בביטריקס, יותר מ-200 פרויקטים של אופטימיזציית ביצועים. שותף מוסמך 1C-Bitrix, המבטיח תהליך שקוף ותוצאות מדידות. אנו משתמשים בשיטות עבודה מומלצות המתוארות בתיעוד הרשמי.
שאילתות JOIN בביטריקס הן תוצאה של החלטה ארכיטקטונית לאחסן את כל המאפיינים בטבלה אוניברסלית. בהיקפים קטנים, זה עובד. ככל שהנתונים גדלים, יש צורך להוסיף אינדקסים או לשנות את סכמת האחסון ל-HL-blocks או טבלאות מותאמות אישית. נעזור לכם לבחור את הדרך האופטימלית. בקשו ייעוץ — ננתח את הפרויקט שלכם ונציע את הפתרון הטוב ביותר. צרו קשר לבדיקה חינמית.