פיצול טבלאות MySQL עבור 1C-Bitrix הוא טכניקה שפותרת את הבעיה של טבלת b_stat_hit שגדלה ל-50 מיליון שורות, כאשר מחיקת רשומות ישנות נועלת את הטבלה לדקות, ו-SELECT לפי טווח תאריכים עובר סריקה מלאה. זה אופייני לפרויקטים ללא פיצול. המהנדסים שלנו עם ניסיון של 10+ שנים, הסמכת Bitrix, ולמעלה מ-50 פרויקטים מוצלחים מבטיחים יישום נכון ללא השבתה. פיצול מפצל טבלת MySQL למקטעים פיזיים. שאילתות פוגעות רק במקטע הנדרש, ומחיקת נתונים ישנים היא DROP PARTITION מיידית במקום DELETE כבד. בפרויקט אחד עם 80 מיליון כניסות סטטיסטיקה, זמן מחיקת נתונים לחודש ירד מ-12 דקות ל-0.1 שניות — שיפור של פי 7200. בפרויקט אחר עם קטלוג של 500,000 מוצרים ו-100,000 מבקרים יומיים, b_stat_hit גדל ב-3 מיליון שורות ביום — לאחר הפיצול, בעיות הנעילה נעלמו.
פיצול אינו פתרון קסם, אבל עבור טבלאות גדולות עם ממד זמן הוא נותן שיפור ביצועים של פי 10-50 בפעולות בחירה וניקוי. אנו משתמשים בפיצול RANGE לפי תאריך — האפשרות השקופה והניתנת לתחזוקה ביותר עבור Bitrix. להלן, אנו מפרטים אילו טבלאות לפצל קודם וכיצד ליישם זאת ללא השבתה.
אילו טבלאות Bitrix יש לפצל?
לא כל הטבלאות מרוויחות מפיצול. מועמדות הן טבלאות גדולות עם ממד זמן:
| טבלה | תוכן | דפוס גידול | המלצה |
|---|---|---|---|
b_stat_hit |
סטטיסטיקת כניסות | אלפי שורות ביום | חובה לפצל |
b_stat_session |
מפגשי מבקרים | אלפי שורות ביום | לפצל |
b_event_log |
יומן אירועים | מאות שורות ביום | לפצל |
b_sale_order_history |
שינויי היסטוריית הזמנות | עשרות שורות ביום | אם נפח > 1M |
b_search_content |
אינדקס חיפוש | גדל עם הקטלוג | אם נפח > 5M |
b_iblock_element_property |
מאפייני אלמנטים של בלוק מידע | גדל עם הקטלוג | אם נפח > 10M |
טבלאות סטטיסטיקה הן המועמד העיקרי: נתונים ישנים מ-3 חודשים נדירים, ו-DELETE FROM b_stat_hit WHERE DATE_HIT < NOW() - INTERVAL 3 MONTH על 30 מיליון שורות לוקח 10 דקות של נעילה. לאחר הפיצול, המחיקה אורכת אלפיות שנייה.
למה זה חשוב לביצועי Bitrix?
ללא פיצול, MySQL סורק את כל הטבלה גם אם רק נתונים משבוע שעבר נדרשים. עם פיצול, האופטימייזר מבצע קיצוץ מקטעים — הוא מדלג על מקטעים שאינם תואמים ל-WHERE. זה מפחית עומס I/O ו-CPU בעשרות מונים. לדוגמה, SELECT עם מסנן תאריך על טבלה מפוצלת רץ פי 30-50 מהר יותר. הנה השוואה זה לצד זה:
| פעולה | נפח נתונים | זמן לפני פיצול | לאחר פיצול |
|---|---|---|---|
| מחיקת כניסות ישנות | 10M שורות | ~5 דקות (נעילה) | 0.001 שניות (DROP PARTITION) |
| SELECT לפי חודש | 5M שורות | ~8 שניות (סריקה מלאה) | ~0.2 שניות (קיצוץ מקטעים) |
האצה כזו משפיעה ישירות על מהירות הדוחות וניקוי היומנים. צרו קשר לניתוח מסד נתונים והערכת השפעה.
איך לאוטומט את סיבוב המקטעים?
לאחר הגדרת הפיצול, יש להוסיף ולהסיר מקטעים באופן קבוע. אנו משתמשים בסקריפט cron ב-Bash שפועל חודשית. לוגיקה לדוגמה:
#!/bin/bash MONTH=$(date +%Y-%m) PART_NAME="p_$MONTH" SQL="ALTER TABLE b_stat_hit REORGANIZE PARTITION p_future INTO (PARTITION $PART_NAME VALUES LESS THAN (TO_DAYS('$(date +%Y-%m-%d -d '+1 month'))'), PARTITION p_future VALUES LESS THAN MAXVALUE);" mysql -u user -p db -e "$SQL" # Удаление старой партиции, например, старше 6 месяцев OLD_PART=$(date +%Y-%m -d '-6 months') OLD_SQL="ALTER TABLE b_stat_hit DROP PARTITION p_$OLD_PART;" mysql -u user -p db -e "$OLD_SQL" הסקריפט חייב להחזיק בהרשאות שינוי טבלה. אנו מגדירים אותו על השרת ובודקים סיבוב אוטומטי.
איך אנו מיישמים פיצול: שלב אחר שלב
- ניתוח טבלאות מועמדות: גודל, דפוסי שאילתות, מהירות גידול.
- שינוי מפתחות ראשיים אם נדרש (הוספת עמודת תאריך).
- יצירת מקטעי RANGE לפי תאריך. דוגמה עבור
#!/bin/bash MONTH=$(date +%Y-%m) PART_NAME="p_$MONTH" SQL="ALTER TABLE b_stat_hit REORGANIZE PARTITION p_future INTO (PARTITION $PART_NAME VALUES LESS THAN (TO_DAYS('$(date +%Y-%m-%d -d '+1 month'))'), PARTITION p_future VALUES LESS THAN MAXVALUE);" mysql -u user -p db -e "$SQL" # Удаление старой партиции, например, старше 6 месяцев OLD_PART=$(date +%Y-%m -d '-6 months') OLD_SQL="ALTER TABLE b_stat_hit DROP PARTITION p_$OLD_PART;" mysql -u user -p db -e "$OLD_SQL":
ALTER TABLE b_stat_hit PARTITION BY RANGE (TO_DAYS(DATE_HIT)) ( PARTITION p_jan VALUES LESS THAN (TO_DAYS('2099-02-01')), PARTITION p_feb VALUES LESS THAN (TO_DAYS('2099-03-01')), PARTITION p_mar VALUES LESS THAN (TO_DAYS('2099-04-01')), PARTITION p_future VALUES LESS THAN MAXVALUE ); תיעוד MySQL Partitioning דורש שעמודת הפיצול תהיה חלק מכל אינדקס ייחודי ומפתח ראשי. עבור b_stat_hit, המפתח הראשי הוא ALTER TABLE b_stat_hit PARTITION BY RANGE (TO_DAYS(DATE_HIT)) ( PARTITION p_jan VALUES LESS THAN (TO_DAYS('2099-02-01')), PARTITION p_feb VALUES LESS THAN (TO_DAYS('2099-03-01')), PARTITION p_mar VALUES LESS THAN (TO_DAYS('2099-04-01')), PARTITION p_future VALUES LESS THAN MAXVALUE ); . אנו משנים אותו למפתח מורכב:
ALTER TABLE b_stat_hit DROP PRIMARY KEY, ADD PRIMARY KEY (ID, DATE_HIT); ALTER TABLE b_stat_hit PARTITION BY RANGE (TO_DAYS(DATE_HIT)) (...); אנו מוודאים ש-Bitrix אינו משתמש ב-b_stat_hit עבור JOINs — אם כן, המפתח המורכב בטוח.
-
הגדרת סקריפט cron לסיבוב מקטעים:
- יצירת מקטע חדש:
ID. - מחיקת ישן:
ALTER TABLE b_stat_hit DROP PRIMARY KEY, ADD PRIMARY KEY (ID, DATE_HIT); ALTER TABLE b_stat_hit PARTITION BY RANGE (TO_DAYS(DATE_HIT)) (...);.
בדיקת ביצועים: מדידת זמני SELECT ו-DELETE לפני ואחרי. בדרך כלל השיפור הוא פי 10-50, ומחיקת נתונים מהירה פי אלפים.
מה כלול בעבודה שלנו
- ניתוח מסד נתונים וזיהוי טבלאות מועמדות.
- שינוי מפתח ראשי ללא אובדן נתונים.
- יצירת מקטעי RANGE לפי תאריך.
- פיתוח והגדרת סקריפט cron לסיבוב אוטומטי.
- בדיקת תאימות עם עדכוני ליבת Bitrix.
- תיעוד כל השינויים.
- תמיכה לאחר היישום (חודש אחד).
בקשו ייעוץ עם מהנדס פיצול. אנו ננתח את מסד הנתונים שלכם ונציע פתרון אופטימלי.
מגבלות בהקשר Bitrix
- עדכוני ליבה. מודול
IDעשוי לבצע ALTER TABLE בעדכון — אם המבנה משתנה והמקטעים לא נלקחים בחשבון, העדכון עלול להישבר. אנו מנהלים רשימה של טבלאות מפוצלות ובודקים לפני כל עדכון. - ORM D7.
REORGANIZE PARTITION p_future INTO (PARTITION p_apr VALUES LESS THAN (TO_DAYS('2099-05-01')), PARTITION p_future VALUES LESS THAN MAXVALUE)אינו מודע למקטעים — שאילתות עובדות בשקיפות, אך האופטימייזר של MySQL מבצע קיצוץ מקטעים רק אם ה-WHERE כולל את עמודת הפיצול. - מגבלות InnoDB. מקסימום 8192 מקטעים לטבלה (MySQL 8). עבור פיצול חודשי, זה מעל 680 שנה.
פיצול טבלאות MySQL עבור 1C-Bitrix הוא דרך מוכחת לשיפור ביצועים, במיוחד בפרויקטים בעומס גבוה. קבלו ייעוץ חינם ממהנדס פיצול. בקשו ניתוח ביצועים היום.
- יצירת מקטע חדש:







