אני מריץ את השאילתה הזו

קוד PHP:

 $comments=mysql_query("SELECT * FROM `comments_form` WHERE topic_id='".$topic."'   ");

$rows_number = mysql_num_rows($comments); 


ואני רוצה לעשות על זה LIMIT

קוד PHP:

 ORDER BY id  DESC LIMIT ".$pnav_un.",".$post_perpage."; 


בכוונה לא עשיתי באותה שאילתה כי אני רוצה ש $rows_number יחזיר את מספר
התוצאות בלי ה LIMIT
איך אני עושה דבר כזה???

לקבל את התוצאות, ולעשות את המיון הזה באמצעות השפת תסריט, או להעתיק את השאילתא שוב ולהוסיף לה את פסקת הORDER.

2 אופציות ששתיהן שגויות

לפותח האשכול:

הרץ רק את השאילתא המלאה, כולל ה LIMIT. הוסף את המילה השמורה SQL_CALC_FOUND_ROWS אחרי SELECT ולפני הכוכבית.

זה יחזיר רק את התוצאות שאתה רוצה.

לאחר מכן, הרץ שאילתא:

קוד:

 SELECT FOUND_ROWS() AS num_rows

ותסתכל על הערך שחוזר ממנה.

http://dev.mysql.com/doc/refman/5.0...tion_found-rows

נמאס לכם לזכור סיסמאות? לחצו כאן!

הן לא שגויות פשוט לא הכרתי את האופציה הזאת

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

שאילתא שתספור את הנתונים, ושאילתא שתמשוך את הנתונים זה לא אותו דבר, אני מאמין שבMySQL מספיק חכמים כדי לא לבצע שליפה מלאה כשאני עושה סה"כ

קוד:

SELECT COUNT(*) FROM `tableName`

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

COUNT (וגם SQL_CALC) לא אמורות לשלוף את כל הנתונים ולא אמרתי שהן שולפות. הן כן עוברות על אותו dataset פעמיים כדי להשיג את התוצאות שלהן - כאשר בפעם השנייה יש סיכוי לא רע (אך לא מחייב) שהמידע כבר ב cache ולכן אולי תרגיש את זה פחות.

אבל אם נעבור כרגע על תכנות באופן כללי, מה עדיף:

* לעשות לולאת for שרצה על מערך בן 5000 ערכים, ועבור כל ערך שערכו משהו, מעלה מונה ב 1; ואז לעשות לולאה נוספת, זהה, שרצה על אותו מערך בין 5000 ערכים, ועבור כל ערך שערכו משהו, להדפיס את המשהו

או:

* לעשות לולאת for שרצה על מערך בן 5000 ערכים, ועבור כל ערך שערכו משהו, להעלות מונה ב 1, ולהדפיס אותו?

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

נמאס לכם לזכור סיסמאות? לחצו כאן!

כדאי להוסיף לשאילתא את פסקת ה-LIMIT, ולאחר מכן לספור את סה"כ הרשומות בעזרת אינדקס ופונקציית COUNT, לדוגמא:

קוד:

/* Fetch the rows */
SELECT * FROM `comments_form` WHERE topic_id=@topic_id ORDER BY `id` DESC LIMIT @offset, @rows_cnt
/* Count the rows, using an index (inspect the query plan) */
SELECT COUNT(*) AS `topic_rows_cnt` FROM `comments_form` WHERE topic_id=@topic_id

(המילים שיש להם קידומת "@" הם משתני SQL, במקומם תצטרך לשים מספר)
זה בהנחה שיש אינדקס על הטורים (`topic_id`, `id`), לפי הסדר.
כדאי גם שתבדוק את ה-query plan בעזרת הוספת קידומת "EXPLAIN" לשאילתא המקורית. אם עבור השאילתות כתוב בטור Extra את המילים "Using Index" אז זה בסדר.

בהנחה שאתה רוצה להציג תוצאות המחולקות לעמודים, תוכל גם לשלוף N+1 רשומות, ולהציג רק N רשומות. אם הצלחת לקבל N+1 רשומות, סימן שיש עוד תוצאות, ולכן תוכל להציג גם קישור "לעמוד הבא". (במקום שתצטרך לספור את כל התוצאות)

אגב, שים לב שזה פורום SQL ולא PHP (תראה כאן הסבר מפורט)

לא, זה לא מה שכדאי...

http://www.fresh.co.il/vBulletin/sh...485#post3701278

נמאס לכם לזכור סיסמאות? לחצו כאן!

למה לא...? אאל"ט SQL_CALC_FOUND_ROWS במקרה שלנו גורם ל-MySQL לספור את כל הרשומות בטבלה מבלי להשתמש באינדקס..

עריכה: To SQL_CALC_FOUND_ROWS or not to SQL_CALC_FOUND_ROWS?

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

תחשוב על זה - אם אתה היית מממש את הפונ' הנ"ל, מה בעצם היא הייתה עושה אם היא נכתבה נכון (ואנחנו צריכים להניח שהם לא סתם הוסיפו פונ' כזו אלא אם כן היא באמת משפרת כמו שהם אומרים במדריך עצמו שנתתי לינק אליו) ? סביר שהיא הייתה עושה בדיוק מה ששתי השאילתות שלך עושות, רק שהיא הייתה עושה זאת בריצה אחת - כאשר היא מספקת מידע לקליינט לפי הגבול שהתבקש, ואז ממשיכה הלאה לספור. שים לב שבדוגמא שצרפת יש שאילתא גם מאוד מאוד בנאלית; לרוב, שאילתות (ובפרט, שאילתות "דפדפוף", שבגללן משתמשים בפונ' הזו) - הן לא כאלה. יש JOIN-ים, יש GROUP BY-ים, יש WHERE-ים... בשאילתות כאלה בכל מקרה חייבים לעבור תמיד על כל הרשומות (כי אתה עושה ORDER BY וסינון, וחייבים לעבור בעצם על כל הרשומות [או האינדקס במקרה שאתה מיועל] כדי לספק ספירה נכונה ל COUNT) - ואז זה לא משנה ממש אם אתה עושה את זה עם SQL_CALC_FOUND_ROWS או אם שאילתא נוספת, למעט ה overhead הנוסף של שאילתא נוספת, "טחינה" חוזרת של ה cache (שבינתיים יכל גם להתנקות או שהטבלה יכלה להשתנות ואז צריך לעבור מחדש...) - ולכן, לסיכום, זה פשוט לא סביר שב USE CASE אמיתי, כזה שבו שתי השאילתות הן זהות, רק שבאחת יש LIMIT ובשנייה אין, ובייחוד בשאילתות "מסובכות", ש SQL_CALC_FOUND_ROWS לא יהיה מהיר יותר...

אבל אם בדקת ובמקרה שלך שתי השאילתות הזהות, ה COUNT עובד יותר מהר... (ואין לך בעייה באינדקסים)... אז וואלה, לך על זה, ונשמע שמצאת וואחד באג.

נמאס לכם לזכור סיסמאות? לחצו כאן!

נכון, סה"כ צריך תמיד לבדוק בעצמך ולא לסמוך על מה שכתוב. במקרה שלנו זה ככל הנראה יהיה מהיר יותר להשתמש ב-COUNT.

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

במקרים שבהם SQL_CALC_FOUND_ROWS מהיר יותר מ-COUNT, זה כנראה בגלל שהרשומות שנותרו לספירה הן מעטות.
שליחה של שאילתא נוספת שמבצעת ספירה כללית (גם על הרשומות שמוחזרות ללקוח בעקבות ה-LIMIT) דרך אינדקס תעמיס יותר מאשר ספירת הרשומות המעטות הנותרות, וכנראה לכן יוצא שזה מהיר יותר...

סה"כ תמיד צריך לבדוק

אתה בדקת על אותה שאילתא שיש בה שימוש באינדקס, שביצוע SQL_CALC (בלי שום שינוי אחר) - מבטל את השימוש באינדקס?

נמאס לכם לזכור סיסמאות? לחצו כאן!

לא.. הייתי צריך? כתוב בקישור שהבאתי :/

אתה זה שאמרת שצריך תמיד לבדוק...

נמאס לכם לזכור סיסמאות? לחצו כאן!

אבל אני בדר"כ עצלן לעשות בדיקות on the fly... גם עשיתי פירמוט למחשב ואני צריך להתקין את התוכנות וזה וזה...

אז בהזדמנות תעשה...

פשוט אני ניסיתי עכשיו EXPLAIN לפני SQL_CALC ואחרי SQL_CALC, בשניהם כתוב לי Using Index...

נמאס לכם לזכור סיסמאות? לחצו כאן!

אוקיי, נשמע מעניין שזה נתן Using Index

תוכל להוסיף פרטים כדי שאוכל להשוות? לדוגמא:
* השאילתות שהרצת
* מבנה הטבלה (כולל מנוע הטבלה, ואינדקסים)
* גירסת MySQL
* כמות המידע שבטבלה (כמות רשומות שהכנסת, ואם אפשר גם את הגודל שלה)

תודה

עזוב, בדוק על כל test case שלך. מעניין אותי

ואל תשכח: שלא יהיה שום הבדל בין השאילתא עם ה LIMIT לבין השאילתא עם ה SQL_CALC. שההבדל היחיד בין שתי שורות השאילתא יהיה ה SQL_CALC - לא בייט אחד פחות ולא בייט אחד יותר.

נמאס לכם לזכור סיסמאות? לחצו כאן!

ציטוט:

במקור נכתב על ידי שימי ואל תשכח: שלא יהיה שום הבדל בין השאילתא עם ה LIMIT לבין השאילתא עם ה SQL_CALC. שההבדל היחיד בין שתי שורות השאילתא יהיה ה SQL_CALC - לא בייט אחד פחות ולא בייט אחד יותר.

אני מניח שהתכוונת "שלא יהיה הבדל ... חוץ מ- SQL_CALC ו-LIMIT", כיוון שחובה להסיר את LIMIT כשסופרים את סה"כ הרשומות בשיטה עם ה-COUNT.

אוקי אז יצרתי קובץ עם שאילתות וביקשתי מ-MySQL להריץ אותו ולהכניס את התוצאות לקובץ טקסט.
השתמשתי בטבלה payment שבמסד הנתונים sakila המסופק באתר של MySQL. (אשמח לנסות על טבלה במסד נתונים אחר מהמבחר שלהם אם אתה מכיר משהו שיהיה מתאים יותר).
בחרתי את payment כי מספר הרשומות בו הוא הגדול ביותר מכל שאר הטבלאות במסד sakila.

count_vs_sql_calc.sql, count_vs_sql_calc.txt

התוצאות במבחן הראשון, שבו ה-offset של ה-LIMIT היה 0, מראות בבירור שהשיטה של COUNT מהירה יותר.
התוצאות במבחן השני, שבו ה-offset כמעט מקסימאלי, מראות ששתי השיטות רצות בזמנים דומים\שווים. אני מסיק מכך ש-SQL_CALC גורם לשאילתא לייצר את ה- result set ולאחר מכן לזרוק את כל מה שהוא לא צריך, מה שקורה בדיוק עם LIMIT כשה-offset גדול. השאילתא שסופרת את הרשומות מראה זמן ביצוע של 0.00 שניות, כנראה בגלל שהאינדקס קטן ולוקח ממש מעט זמן לעבור דרכו.

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

או שפשוט תייצר אחת כזו

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

ואם תצליח להוכיח שגם במקרה שבו יותר הגיוני שמשתמשים בזה - זה גם איטי יותר, אני בהחלט אשקול לעשות שני דברים:

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

2. לפנות גם לחבר'ה של WordPress, שיעיפו את:

קוד:

                if ( !empty($limits) )
                        $found_rows = 'SQL_CALC_FOUND_ROWS';

                $this->request = " SELECT $found_rows $distinct $fields FROM $wpdb->posts $join WHERE 1=1 $where $groupby $orderby $limits";

מ query.php שלהם :|

נמאס לכם לזכור סיסמאות? לחצו כאן!

אם אייצר אחת כזו זה לא יהיה אותנטי (המידע יוצר באופן שרירותי), אני לא אוהב להסתמך על זה.
הורדתי מסד נתונים ענק מ- https://launchpad.net/test-db/ שנקרא employees.
בהתחלה עשיתי ניסויים על הטבלה salaries כיוון שיש בה 2.8 מיליון רשומות. הבעיה בטבלה הזו היא ייחודיות הערכים בטורים (cardinality) שהייתה נמוכה מאוד (ולפיכך אם היינו רוצים לשלוף לדוגמא 20 רשומות, אז היה לנו עמוד אחד). זה לא טוב ולא מראה את התוצאות המתבקשות, אבל בכל זאת בדקתי באמצעות הטבלה הזאת.
תוצאות שהתקבלו באמצעות בדיקות על הטבלה salaries:
CvS.html, CvS.sql.

אחרי זה השתמשתי בטבלה dept_emp שה-cardinality בה היה גבוה מאוד (ניתן לראות זאת בקובץ התוצאות).
עשיתי ארבעה בדיקות: עבור offset נמוך, עבור offset גבוה, בדיקות ל-COUNT עם offset גבוה ואופטימיזציה מעטה, בדיקות ל-COUNT עם offset גבוה ואופטימיזציה מירבית.
SQL_CALC התברר כיעיל מול COUNT אך ורק במקרים שבהם: ה-offset גבוה ול-COUNT אין אופטימיזציה, ושה-offset גבוה ו-COUNT קיבל אופטימיזציה מעטה.
בשאר המקרים, COUNT גובר עליו משמעותית, במיוחד במקרה האופטימיזציה המירבית.
התוצאות (זמין בפורמט html ו-txt):

CvS_Real.txt
CvS_Real.html
CvS_Real.sql

אשמח לקבל תיקונים אם משהו שם בוצע לא נכון \ לא שמתי לב למשהו

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

בדוגמא השנייה - אני שם לב שהחיפוש מתבצע על טור טקסטואלי. יש סיבה שהוא לא אינדקס FULLTEXT ולא נעשה חיפוש FULLTEXT ?

ולבסוף, שמתי לב שמסדי הנתונים הם מסוג InnoDB, בעוד שרוב התעשיה משתמשת לרוב ב MyISAM (ה"בוגר" בכמה שנים טובות יחסית ל InnoDB), וב InnoDB משתמשים רק לפעמים לסוגי טבלאות מאוד מסויימים (UPDATE-ים בכמויות לתאים בודדים ורצון לא לנעול את כל הטבלה בזמן שהם מתרחשים). יש סיבה מיוחדת?

נמאס לכם לזכור סיסמאות? לחצו כאן!

בדוגמא השנייה אין סיבה מיוחדת לכך שהוא לא FULLTEXT (מלבד זה שאם הוא היה FULLTEXT אז הייתה בעיה בנוגע ל-PRIMARY KEY :/).
זה פשוט לא מתאים FULLTEXT לדעתי.

דווקא חשבתי ש- InnoDB הוא הכי נפוץ כיוון שהוא מאפשר גישה לטבלה "במקביל", וגם בזכות תכונות ה-ACID שהוא נותן.

(ככה קיבלתי את הטבלאות מהמקום שממנו הורדתי, אלו הגדרות הברירת מחדל, חוץ מהאינדקס שיצרתי בדוגמא השנייה)

גם בבדיקה הזו, התוצאות לטובת COUNT.
תראה: s.sql, s.txt

בבדיקה האחרונה (אופטימיזציה מירבית) משום מה ה-EXPLAIN כותב Using where, וטור ה-type כותב ref.
זה היה אמור להיות:
Extra = Using index
type = index
על מנת שהתת-שאילתא תשתמש ב-covering index. (שזה מה שכתבתי בקובץ התוצאות, אבל זה כנראה לא נכון, בטעות לא שמתי לב)

אני צריך לבדוק את זה..

אם אני מכריח אותו להשתמש באינדקס dept_no_from_date_idx בעזרת פיסקת FORCE INDEX, אז השאילתא כן משתמשת ב-covering index. אחרת לא...
שזה מוזר ואני לא מבין למה ...

אני חושב שזה באג ב-EXPLAIN עבור המנוע InnoDB. שלחתי דו"ח על הבאג.

אני שאלתי שאלה ממש קטנה וכבר יש 20 תגובות
שמתוכחות על כל מיני דברים.

באמת אני למדתי בניית אתרים בפורום אחר (שרובכם בודאי מכיר)
ורק בגלל שהרמה שם לא רצינית אני מחפש מקום אחר.
רק אם מנהל פה היה נותן את המילה שלו
ומתערב בויכוחים כאלה, וגם מוסיף מדריכים או משהו (אני מדבר גם על PHP, SQL, ובניית אתרים )
הייתי בודאי פעיל פה הרבה.

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

לא הבנתי את הנקודה.

אנחנו לא מתווכחים חלילה, אלא מנסים לבדוק מה טוב יותר ובאיזה מקרים. (זה מה ש-DBAs עושים...)