שלום לכם,
הטבלה שלי מכילה כ 13 שדות מסוג INT ועוד שדה מסוג מחרוזת. בטבלה אמורים להיות מאות אלפי ואף מליוני רשומות.
אני צריך לבצע סינון על הטבלה , מיון לפי עמודות [לא שדה המחרוזת].
את הטבלה מחולקת לעמודים בגודל 100, נניח, אני מציג בדף ASP .
בדיקות שערכתי העלו כי זמני הריצה של השאילתות בילתי סבירים.לדף ASP ךוקח המון זמן להטען.
אני משתמש ב mysql , הגדרתי אינדקסים על השדות שאותן אפשר למיין ולסנן.
האם יש לכם עיצה מה לעשות כדי לשפר באופן דרמטי את הביצועים? אולי האינדקסים לא מוגדרים נכון?
אגב אם יש שירשורים על נושא זה אשמח לקבל קישור.
אני מצרף קוד [לטבלה בנתיים נוספו שדות אבל זה הרעיון]

CREATE TABLE `t_history` (
`ID` int(10) unsigned NOT NULL auto_increment,
`f_client_id` int(11) default NULL,
`f_device_types_id` int(11) default NULL,
`f_priority` tinyint(3) default NULL,
`f_update_time` datetime default NULL,
`f_sort` int(11) default NULL,
UNIQUE KEY `ID` (`ID`),
KEY `i_h_client_id` (`f_client_id`),
KEY `i_f_device_types_id` (`f_device_types_id`),
KEY `i_f_update_time` (`f_update_time`)
)

אמממ חסר טיפה מידע איזה סוג אינדקסים הגדרת ועל איזה שדות ?

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

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

אז אם כל משתמש שולח רשומה פעם ביום, תוך כמה שבועות יצטברו מאות אלפי רשומות

אני ממליץ לך בחום לקרוא פה
http://dev.mysql.com/doc/userguide/...xing-types.html
ואם אתה מדבר על עשרות אלפי משתמשים הייתי ממליץ לך לחשוב שוב מה המסד נתונים האופטימלי בשבילך.

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

בלי השאילתא עצמה יהיה קשה לתת לך המלצות

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

_________________________________________________

אזהרה: משרד הבריאות קובע כי העישון מזיק לבריאות !
תראו, אפילו החייזר נהיה ירוק מזה

מנהל פורום מדע בדיוני ופנטסיה ופורום מדע טכנולוגיה וטבע בפרש

קוד:

 select ID, f_client_id as uname, f_update_time, f_sort, f_modem, f_wwan, f_lan, f_wifi, f_Bluetooth, f_1394, f_usb, f_cd_rom, f_floppy, f_Irda, f_details 

from t_history ORDER BY t_history.f_update_time DESC LIMIT 209760,40 

פסוקית הלימיט נועדה כדי לחלק לעמודים בתצוגת ה ASP

ב DB יש נכון לעכשיו חצי מליון רשומות. זמן החזרה של שאילתה עומד על מס' דקות! זמן בלתי סביר. אני רוצה פחות משניה ועד 2-4 שניות מקס' במקרה הכי גרוע.

ה- LIMIT בעייתי משהו..
209760 גדול מ-40.

בכל מקרה אני חושב שאם תקטין את המידע לדף אחד יהיה עדיף, זה גם נוח יותר למשתמש לראות כל-פעם פחות מידע, לא לפוצץ אותו, וגם טוב ל-MySQL שייתעסק עם פחות מידע

זה לא משנה - ה-40 מציין את מספר השורות המירבי שיש להחזיר אחרי 209760

טוב לדעת

תודה לעונים