אופטימיזציה מקצועית של אינדקסים במסד נתונים עבור 1C-Bitrix

לעתים קרובות אנו רואים פרויקטים שבהם שאילתת קטלוג על 50,000 מוצרים אורכת 4 שניות במקום 40 אלפיות השנייה. EXPLAIN מציג ALL במקום ref — הטבלה נסרקת לחלוטין. זהו סימפטום קלאסי: אינדקסים לא נוספו לאחר גידול בנתונים או שנמחקו בטעות במהלך עדכוני סכמה. חשיבות האינדקסים מתועדת היטב בוויקיפדיה. במשך למעלה מ-10 שנות עבודה, למדנו לזהות בעיות כאלה תוך דקות ולחסל אותן עם תוצאות מובטחות.

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

אילו אינדקסים קריטיים עבור בלוקי מידע?

מבנה האחסון של נתוני בלוקי המידע מפוצל על פני מספר טבלאות. להלן העיקריות עם אינדקסים מומלצים:

בסביבת ייצור, b_iblock_element_property מגיע בקלות ל-10-30 מיליון שורות. שאילתת מסנן לפי שני מאפיינים ללא אינדקס גורמת לסריקה מלאה של שתי הטבלאות, מה שגורם לעיכובים של שניות באופן מיידי.

כיצד לאבחן שאילתות איטיות?

ראשית, הפעל את יומן השאילתות האיטיות ב-MySQL/MariaDB:

SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log'; 

במקביל, השתמש בפרופילינג של ביטריקס באמצעות קבועים ב-SET GLOBAL slow_query_log = 'ON'; SET GLOBAL long_query_time = 1; SET GLOBAL slow_query_log_file = '/var/log/mysql/slow.log'; :

define("DBDebug", true); define("DBDebugToFile", true); 

היומן נכתב אל dbconn.php. הפעל אותו לזמן קצר בסביבת ייצור — הקובץ גדל באופן מיידי. נתח את 10 השאילתות האיטיות ביותר וסקור את התוכניות שלהן באמצעות define("DBDebug", true); define("DBDebugToFile", true); .

כיצד אנו מוסיפים אינדקסים חסרים?

בדוק אם קיימים אינדקסים באמצעות:

SHOW INDEX FROM b_iblock_element; SHOW INDEX FROM b_iblock_element_property; 

הוסף את כל האינדקסים הדרושים בבת אחת:

ALTER TABLE b_iblock_element ADD INDEX ix_ie_iblock_active_date (IBLOCK_ID, ACTIVE, DATE_ACTIVE_FROM); ALTER TABLE b_iblock_element_property ADD INDEX ix_iep_iblock_prop_val (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE), ADD INDEX ix_iep_element_prop (IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID); ALTER TABLE b_catalog_price ADD INDEX ix_cp_catalog_price (CATALOG_GROUP_ID, PRICE, CURRENCY); ALTER TABLE b_catalog_store_product ADD INDEX ix_csp_product_store (PRODUCT_ID, STORE_ID); ALTER TABLE b_stat_phrase_date ADD INDEX ix_spd_date_phrase (DATE1, PHRASE_ID); 

כל השינויים מבוצעים באמצעות bitrix/modules/main/tools/bx_sql.log על טבלאות הגדולות מ-1 GB כדי למנוע נעילות.

מדוע מטמון אינו פותר את הבעיה?

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

תחזוקת אינדקסים היא קריטית לביצועים

אתרי ביטריקס עם מודול EXPLAIN צוברים מיליוני שורות בטבלאות SHOW INDEX FROM b_iblock_element; SHOW INDEX FROM b_iblock_element_property; . לאחר מחיקות המוניות דרך לוח הניהול, אינדקסים הופכים למפוצלים, וסטטיסטיקת התפלגות הנתונים הופכת למיושנת. אנו מנתחים פיצול:

SELECT TABLE_NAME, ROUND(DATA_FREE/1024/1024, 2) AS free_mb, ROUND(DATA_LENGTH/1024/1024, 2) AS data_mb FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'bitrix_db' AND DATA_FREE > 10485760 ORDER BY DATA_FREE DESC; 

כאשר הפיצול עולה על 20% מהנתונים, אנו מריצים ALTER TABLE b_iblock_element ADD INDEX ix_ie_iblock_active_date (IBLOCK_ID, ACTIVE, DATE_ACTIVE_FROM); ALTER TABLE b_iblock_element_property ADD INDEX ix_iep_iblock_prop_val (IBLOCK_ID, IBLOCK_PROPERTY_ID, VALUE), ADD INDEX ix_iep_element_prop (IBLOCK_ELEMENT_ID, IBLOCK_PROPERTY_ID); ALTER TABLE b_catalog_price ADD INDEX ix_cp_catalog_price (CATALOG_GROUP_ID, PRICE, CURRENCY); ALTER TABLE b_catalog_store_product ADD INDEX ix_csp_product_store (PRODUCT_ID, STORE_ID); ALTER TABLE b_stat_phrase_date ADD INDEX ix_spd_date_phrase (DATE1, PHRASE_ID); (בנייה מחדש מלאה ב-InnoDB) או משתמשים ב-pt-online-schema-change למצב מקוון.

סימפטומים אופייניים ופתרונות

מה כלול בעבודה שלנו?

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

אנו מבטיחים שלאחר הכוונון שלנו, זמן הביצוע של שאילתות טיפוסיות יקטן פי 10–100. אנו מאשרים זאת עם תוצאות בדיקות לפני/אחרי. לדוגמה, בפרויקט אחד עם קטלוג של 200,000 מוצרים, הפחתנו את זמן טעינת העמוד הראשי מ-8 שניות ל-0.2 שניות — פי 40 מהר יותר מכל אופטימיזציית מטמון. החיסכון במשאבי שרת הסתכם בכ-150,000 רובל לחודש, ועלות השכרת השרת ירדה ב-40%.

לוח זמנים ועלות

משך העבודה המשוער — בין 2 ל-5 ימי עסקים, תלוי בנפח הנתונים ובמורכבות הסכמה. העלות מחושבת באופן אישי לאחר ביקורת. אנו מצטטים את המחיר בשקיפות לפני תחילת העבודה ואינם מסתירים אפשרויות נוספות.

הזמן ביקורת אינדקסים — נזהה צווארי בקבוק תוך יום אחד. קבל ייעוץ: נעריך את הפרויקט שלך בחינם. ניסיון של 10+ שנים ו-50+ פרויקטים של אופטימיזציית מסדי נתונים מדברים בעד עצמם.

אתה יכול גם ללמוד את התיעוד הרשמי של MySQL על אינדקסים להבנה מעמיקה יותר.