• 0 رای - 0 میانگین
  • 1
  • 2
  • 3
  • 4
  • 5
یک رفتار غیرقابل پیشبینی هنگام Sort کردن بر اساس Timestamp
#1
البته من فکر میکنم این رفتاری که دیدم فقط محدود به Timestamp نمیشه و ممکنه کلا بر اساس ستونهایی که مقدار رکوردهای اونا یکی باشه پیش بیاد. ولی چیزی که دیدم و تست کردم بر اساس Timestamp بود.

حالا قضیش چیه.
قضیه اینه که من یکسری رکورد در جدول درج کردم که بیشترشون مقدار Timestamp یکسانی داشتن. بعد کوئری ای داشتم که بر اساس Timestamp مرتب میکرد و البته limit و offset هم برای صفحه بندی داشت. بعد چیزی که دیدم این بود که جای بعضی نتایج در صفحات عوض میشد. یعنی مثلا الان رکورد X در صفحهء 1 آمده، بعدش میدیدی رکورد X در صفحهء 2 هم اومده. بعد کل رکوردهایی رو که در تمام صفحات اومده بودن چک میکردی با دیتابیس میدیدی یک رکورد اصلا در هیچ صفحه ای لیست نشده، که بنظرم طبیعتا بخاطر این بوده که اون رکورد تکراری جاش رو گرفته بوده.

من سعی کردم علت این قضیه رو کشف کنم و یکسری تست انجام دادم، و دست آخر به این نتیجه رسیدم که این قضیه از این ناشی میشه که مقدار بیشتر رکوردها در اون ستونی که بر اساس اون مرتب میکنیم برابر بوده، و اینکه الگوریتم Sort یه جورایی در مکان دقیق رکوردها در هر بار بصورت Non-deterministic عمل میکنه.

خب بعضی الگوریتم ها هستن که اینطورین. و مثلا در بعضی رفرنس ها نوشته که فلان خصیصهء این الگوریتم Non-deterministic هست یا تعریف نشده/تضمین نشده هست.
ممکنه الگوریتم Sort مای اس کیو ال هم در این حالت خاص یک چنین ویژگی ای داشته باشه که مثلا رکوردهایی که از نظر معیار Sort هیچ تفاوتی با هم ندارن ممکنه در کوئری های مختلف در مکانهای مختلفی نسبت به هم بیان. مثلا فرض کنیم رکورد A دارای مقدار 102 در ستون مرتب سازی هست و رکورد B هم دارای مقدار 102 در ستونی که بر اساسش مرتب سازی صورت میگیره. حقیقت اینه که MySQL به شما تضمینی نمیده که همیشه در هر کوئری ای که اجرا میشه ترتیب آمدن A و B یکسان باقی بمونه. یعنی ممکنه در یک کوئری ابتدا A بیاد و بعد B و در کوئری دیگری ابتدا B بیاد و بعد A. از نظر مفهوم کلی مرتب سازی که میشه گفت این قضیه مشکلی نداره، چون در هر دو حالت مرتب سازی بدون اشکاله و این دوحالت از نظر معیار مرتب سازی داده شده، هر دو صحیح هستن. ولی اینکه این ترتیب همیشه ثابت بمونه (به فرض اینکه خود دیتابیس در این مدت دستکاری ای نشده باشه که بتونه مکان فیزیکی رکوردها رو تغییر داده باشه)، بستگی به الگوریتم های استفاده شده و بقیهء اجزای درگیر داره.

حالا این دیتابیس من قبل از اجرای این قضیه دستکاری شده بود و مثلا رکوردهایی رو حذف کرده بودم که باعث میشه یکسری رکوردهای جدیدی که درج میکنید بجای اینکه از نظر فیزیکی در انتهای فایل جدول درج بشن در جای رکوردهای حذف شده ذخیره بشن و این حرفها، اما موقع اجرای این تست ها دیتابیس تغییری نکرده بود که بگیم این ترتیب ممکنه بهم خورده باشه.

بعد من بخاطر همین مشکل، بجای مرتب سازی بر اساس Timestamp از مرتب سازی بر اساس کلید Auto Increment جدول استفاده کردم و مشکل برطرف شد.
کلید Auto Increment اولا از نظر مرتب سازی میتونه بدون مشکل بجای Timestamp استفاده بشه و تازه دقیقتر هم هست، یعنی مثلا اگر دو رکورد در زمان بسیار نزدیکی درج بشن Timestamp اونا (که معمولا دقتش درحد ثانیه هست) میتونه یکسان بشه، اما مقدار Auto Increment کاملا نشون میده که کدام رکورد قبل از دیگری درج شده، و دوما چون مقدار رکوردها در ستون Auto Increment هیچوقت نمیتونه یکسان باشه بنابراین با مشکل و ابهام در زمینهء Non-deterministic بودن مکان دقیق رکوردها نسبت به هم در تمام کوئری ها برخورد نمیکنیم.

گفتم این قضیه رو مطرح کنم ببینم کسی شاید تجربه یا اطلاعاتی در این مورد داشته باشه.
  پاسخ
تشکر شده توسط : masoudmanson
#2
یه سوالی برا من پیش اومد Blush
شما گفتین که ممکنه الگوریتم sort مای اس کیو ال به صورت nondeterministic عمل می کنه و برا همون این اتفاق میوفته!
پس یعنی در این صورت به صورت تصادفی میشه به رکوردهای جدول دسترسی پیدا کردHuh
ولی من فک می کردم که وقتی مثلا ما می خوایم رکورد nام رو از جدول بخونیم ، MySQL از رکورد 1 تا n-1 رو جاروب می کنه تا به رکورد مورد نظر ما برسه!
که اگه اینطوری باشه ، نباید مشکلی که شما بهش اشاره کردین رخ بده Confused
W H A T E V E R   Sleepy 
  پاسخ
تشکر شده توسط :
#3
(۱۳۹۱ خرداد ۱۵, ۰۲:۲۷ ب.ظ)masoudmanson نوشته: پس یعنی در این صورت به صورت تصادفی میشه به رکوردهای جدول دسترسی پیدا کردHuh
منظورت مفهوم نبود.
بصورت تصادفی دسترسی پیدا کردن یعنی چی دقیقا؟

نقل قول:ولی من فک می کردم که وقتی مثلا ما می خوایم رکورد nام رو از جدول بخونیم ، MySQL از رکورد 1 تا n-1 رو جاروب می کنه تا به رکورد مورد نظر ما برسه!
اینجا فقط بحث خوندن عادی نیست. بحث مرتب کردنه، و در مرتب کردن ترتیب رکوردها عوض میشه، و هر الگوریتم مرتب سازی ممکنه به یک شکل متفاوتی این عمل رو انجام بده که در نتیجه مکان نسبی رکوردهای با مقدار یکسان در ستون مرتب سازی میتونه نسبت به هم متفاوت باشه.
البته وقتی الگوریتم ثابت باشه شاید فکر کنیم دیگه نباید این قضیه اتفاق بیفته، ولی این یک تصور سطحی و اثبات نشده هست و شاید جزییات دیگری درکار باشه که به دلایل مختلف اینطور نباشه.

ضمنا خوندن اگر با معیار خاصی نباشه، یعنی مثلا order by نداشته باشه، رکوردها رو بر اساس ترتیب فیزیکی اونا میخونه، که ترتیب فیزیکی هم لزوما با ترتیب درج یکی نیست. مثلا اگر رکورد شماره 5 رو دلیت کنید و بعد رکورد شماره 20 رو درج کنید، ممکنه رکورد شماره 20 در جای سابق رکورد شماره 5 درج بشه. اینطوری وقتی این کوئری رو اجرا کنید:
کد:
select * from `table`
میبینی که رکورد شماره 20 بعد از رکورد شماره 4 نشون داده میشه.
این موضوع رو میدونستی؟
من قبلا تستش کردم.
  پاسخ
تشکر شده توسط :
#4
توی myisam که یادمه کلا جدول به صورت پیشفرض بر اساس یک فیلد خاص مرتب بود(بیشتر کلید اصلی) توی innodb نمی دونم. (باید تحقیق کنم) البته می دونم که توی innodb نمیشه بر اساس یک فیلد خاص مرتب شده قرار داد ولی نمی دونم که بر اساس کلید اصلی مرتب هست یا نه. البته این رفتار توی دیتابیس های متفاوت به صورت متفاوت عمل می کنه. مثلا توی pgsql بر اساس زمان اپدیت و یا insert جاهاشون فرق می کنه. البته راهکارش بسیار راحته. راهکارش این هست که همیشه اگر می خوایین به ترتیب درست قرار بگیرن از sort بر روی کلید اصلی استفاده کنید (یا هر کلید یکتایی) . اگر sort قرار نیست قرار بدید بر اساس اون فیلد (کلید اصلی یا هر فیلد یکتایی) انجام میدیم و اگر sort داشتیم مثلا sort روی فیلد date به صورت sort چندتایی عمل زمی کنیم
کد:
sort date DESC,id DESC
  پاسخ
تشکر شده توسط :
#5
(۱۳۹۱ خرداد ۱۵, ۰۳:۴۱ ب.ظ)admin نوشته: توی myisam که یادمه کلا جدول به صورت پیشفرض بر اساس یک فیلد خاص مرتب بود(بیشتر کلید اصلی) توی innodb نمی دونم.
من که الان تست کردم اینطور نیست:
کد:
mysql> explain test;
+-------+---------+------+-----+---------+----------------+
| Field | Type    | Null | Key | Default | Extra          |
+-------+---------+------+-----+---------+----------------+
| auto  | int(11) | NO   | PRI | NULL    | auto_increment |
| i     | int(11) | NO   |     | NULL    |                |
+-------+---------+------+-----+---------+----------------+
2 rows in set (0.05 sec)

mysql> select * from test;
+------+---+
| auto | i |
+------+---+
|    1 | 1 |
|    2 | 1 |
|   10 | 1 |
|   12 | 1 |
|   11 | 1 |
|    7 | 1 |
|    8 | 1 |
|    9 | 1 |
+------+---+
8 rows in set (0.00 sec)

نقل قول:راهکارش این هست که همیشه اگر می خوایین به ترتیب درست قرار بگیرن از sort بر روی کلید اصلی استفاده کنید (یا هر کلید یکتایی) . اگر sort قرار نیست قرار بدید بر اساس اون فیلد (کلید اصلی یا هر فیلد یکتایی) انجام میدیم و اگر sort داشتیم مثلا sort روی فیلد date به صورت sort چندتایی عمل زمی کنیم
کد:
sort date DESC,id DESC
آره منم همین روش بنظرم رسیده بود و میخواستم بگم.
فقط توی فکر بودم که با این کار آیا یک مرحله Sort بیشتر به هر کوئری اضافه نمیشه و چقدر پرفورمنس رو میاره پایین. مثلا در جدولهایی که تعداد زیادی رکورد دارن. هرچند اگر راه دیگه ای نباشه خب نیست دیگه!!
ضمنا درمورد date دیگه چرا؟ همون فیلد auto_increment رو معیار Sort قرار بدی کافیه دیگه.
من درمورد فیلدهای دیگه میگم که فیلد auto_increment رو هم تهش اضافه کنیم (حالا اضافه کردیم بنظرت ASC باشه یا DESC یا مطابق با فیلد قبلی و چرا؟).



ضمنا وحید بنظرم متوجه منظور اولیهء من نشدیا. این چیزایی که گفتی یه بحث دیگس درواقع.

میدونی من چی میگفتم؟

ولش کن اصلا Big Grin

حیف شد اون دیتابیس و داده های تست رو که داشتم پاک کردم. دیگه هرکاری هم کردم نشد اون شرایط عجیب بازسازی بشه. نمیدونم چرا Huh

اگر اون دیتابیس بود میدادم خودتون تست کنید.
کوئری هاش یه جور دیگه جواب میداد.
نمیدونم والا شایدم MySQL باگی چیزی زده بوده!!
  پاسخ
تشکر شده توسط :
#6
نقل قول:بصورت تصادفی دسترسی پیدا کردن یعنی چی دقیقا؟

یعنی مثلا فرض کنید جدول 100 تا رکورد داره و شما می خواین رکورد 80 ام رو بخونین. اونوقت MySQL یه راس میره سراغ رکورد 80 یا از 1-79 رو رد می کنه تا به 80 برسه؟؟
دسترسی تصادفی اگه اشتباه نکنم میشه اینکه یه راس بره سراغ اون رکوردی که می خوایم Confused

نقل قول:اینجا فقط بحث خوندن عادی نیست. بحث مرتب کردنه، و در مرتب کردن ترتیب رکوردها عوض میشه، و هر الگوریتم مرتب سازی ممکنه به یک شکل متفاوتی این عمل رو انجام بده که در نتیجه مکان نسبی رکوردهای با مقدار یکسان در ستون مرتب سازی میتونه نسبت به هم متفاوت باشه.

مگه مرتب سازی این نیس که رکورد ها رو می خونه و با هم به یه روشی حالا مقایسه می کنه و نتیجه ی مرتب شده رو بر می گردونه Undecided پس به هر حال خوندن رکوردها مطرحه

نقل قول:ضمنا خوندن اگر با معیار خاصی نباشه، یعنی مثلا order by نداشته باشه، رکوردها رو بر اساس ترتیب فیزیکی اونا میخونه، که ترتیب فیزیکی هم لزوما با ترتیب درج یکی نیست. مثلا اگر رکورد شماره 5 رو دلیت کنید و بعد رکورد شماره 20 رو درج کنید، ممکنه رکورد شماره 20 در جای سابق رکورد شماره 5 درج بشه. اینطوری وقتی این کوئری رو اجرا کنید:
کد:
select * from `table`
میبینی که رکورد شماره 20 بعد از رکورد شماره 4 نشون داده میشه.
این موضوع رو میدونستی؟
من قبلا تستش کردم.

اینم نمی دونستم
چقدر عجیب Big Grin
فک کنم order این کار بالا باشه Tongue هر دفعه که می خواد یه رکورد جدید insert کنه باید از اول کل جدول رو بخونه و به اولین جای خالی که رسید رکورد جدید رو اونجا بزاره
به نظر من که منطقی نیست این کار! جای خالی فضای چندانی رو نمی گیره که بخواییم برای پر کردن اون سربار پیمایش جدول از ابتدا رو به دوش بکشیم Big Grin
بازم حتما چیزی می دونن که این کارو کردن دیگه
W H A T E V E R   Sleepy 
  پاسخ
تشکر شده توسط :
#7
(۱۳۹۱ خرداد ۱۵, ۰۸:۱۵ ب.ظ)masoudmanson نوشته: یعنی مثلا فرض کنید جدول 100 تا رکورد داره و شما می خواین رکورد 80 ام رو بخونین. اونوقت MySQL یه راس میره سراغ رکورد 80 یا از 1-79 رو رد می کنه تا به 80 برسه؟؟
بنده چه میدونم! بدیهی هست که یک نرم افزار پایگاه داده معروف و با سابقه ای مثل MySQL میتونه روشهای مختلف و الگوریتم های پیچیده ای برای هرکاری داشته باشه جهت افزایش پرفورمنس و مسائل دیگر.
فرضا اگر رکوردها از نوع با طول ثابت باشن (مثلا اگر در جدولش از ستونهای با طول متغییر استفاده نشده باشه)، نیازی نیست که لزوما تمام رکوردها قبل از رکورد مورد نظر خونده بشن. با یک جمع و ضرب ساده میشه مکان شروع رکورد مورد نظر رو بدست آورد و با توابع سیستم فایل به همونجا seek کرد.

یا مثلا وقتی ایندکس داریم خب ایندکس هم چیزی نیست جز این که مکان شروع رکورد مورد نظر رو در خودش ذخیره کرده تا نیازی نباشه تمام جزییات تمام رکوردهای قبلی رو بخونید تا به رکورد جدید برسید.

اما در مواردی هم ممکنه خوندن تمام رکوردها در بین باشه.

بهرحال اینا ارتباطی به سوال و مورد بنده ندارن. نفهمیدم ربطش چیه! اون کارهایی که MySQL در سطح سیستم فایل خودش انجام میده لزوما به ما مربوط نیست. ما در سطح منطق و تضمین های بالاتر کار داریم. چون همونطور که گفتم شما نمیتونید به این راحتی تمام جزییات طرز کار نرم افزارهای پیچیده ای مثل MySQL رو با اطمینان از قبل پیشبینی کنید و حدس بزنید؛ ممکنه هزار روش و سیستم مختلف به علت های مختلف داشته باشه که فرضیات ما رو تحت تاثیر قرار بدن. بالاخره نرم افزاری هست که حجم و پیچیدگی خودش رو داره و سالها توسعه و بهینه سازی و مسائل دیگر مثل پایداری روش طراحی و پیاده سازی شده.

نقل قول:مگه مرتب سازی این نیس که رکورد ها رو می خونه و با هم به یه روشی حالا مقایسه می کنه و نتیجه ی مرتب شده رو بر می گردونه Undecided پس به هر حال خوندن رکوردها مطرحه
ما به خوندن فیزیکیش لزوما کاری نداریم. چون اولا همونطور که گفتم ممکنه الگوریتمش متفاوت با اون چیزی باشه که ما فکر میکنیم و نمیشه تمام جزییاتش رو بدون تحقیق و مطالعه تخصصی با اطمینان فهمید.
دوما تاجاییکه من بصورت مبهم و جسته و گریخته از اینور و اونور فهمیدم، و تاجاییکه از الگوریتم های مرتب سازی در دوران تحصیل و موارد دیگری که بعدا چیزهایی خوندم یادمه، این رکوردها نهایتا در RAM مرتب و جابجا میشن. یعنی اول خونده میشن و به Memory میرن و بعد در Memory مرتب میشن (اگر الگوریتم های مرتب سازی رو مطالعه کرده باشید حتما دیدید که روی آرایه هایی که طبیعتا در RAM هستن این کار مرتب سازی که نیاز به جابجایی داره انجام میشه). حالا روش پیاده سازی میتونه بصورت لیست پیوندی باشه یا هر روش دیگری. بهرحال موضوع ترتیب این رکوردها بعد از مرتب سازی هست، که این درمورد رکوردهایی که ستون مرتب سازی اونها مقدار برابری داره میتونه بستگی به الگوریتم استفاده شده داشته باشه. مثلا الگوریتم حبابی یک جور مرتب میکنه، الگوریتم Quick sort به یک شکل دیگه، و البته الگوریتم های بیشتر و عجیب تری هم وجود دارن بنظرم، و چه بسا MySQL از الگوریتمی سفارشی شده یا اختصاصی خودش استفاده کرده باشه که با ساختار داخلی و بقیهء بخشها و سیستمهای بهینه سازی خودش هم ارتباط و درگیری داشته باشه.

البته بازم این حرفا لزوما کلی و مطلق نیست.
کاملا ممکنه MySQL از روشهای مختلفی برای مرتب کردن در کوئری های مختلف و جدولها و رکوردها با خصوصیات و حجمهای مختلف استفاده کنه.
معمولا یک راه حل بهینه و مناسب برای تمام موارد وجود نداره. بخصوص که نرم افزار و کارایی های اون تنوع و پیچیدگی و گستردگی ای به این اندازه داشته باشن.

نقل قول:فک کنم order این کار بالا باشه Tongue هر دفعه که می خواد یه رکورد جدید insert کنه باید از اول کل جدول رو بخونه و به اولین جای خالی که رسید رکورد جدید رو اونجا بزاره
به نظر من که منطقی نیست این کار! جای خالی فضای چندانی رو نمی گیره که بخواییم برای پر کردن اون سربار پیمایش جدول از ابتدا رو به دوش بکشیم Big Grin
بازم حتما چیزی می دونن که این کارو کردن دیگه
دربارهء اینطور نرم افزارها خیلی ساده فکر میکنی و مطمئن هستی. روشهای این نرم افزارها لزوما اینقدر ساده نیستن.
هزار جور سیستم و الگوریتم جانبی و بهینه سازی ممکنه داشته باشن. مثلا ممکنه آدرس رکوردهای خالی در یک فایل جداگانه یا در بخش مخصوصی از همون فایل جدول درج میشه. ممکنه در فایل ایندکس مشخص میشه. معلوم نیست چطور پیاده سازی کردن. حتی ممکنه مثلا آدرس فیزیکی تعدادی از حذفهای اخیر رو برای دسترسی سریع در RAM نگهداری کنه.
خلاصه لزوما برای این کار نیازی نیست که همهء رکوردها رو از اول بخونه.
از طرف دیگه لزوما برای تمام انواع جدول و تمام انواع رکورد و همیشه این کار انجام نمیشه. ولی بهرحال امکان داره انجام بشه، همونطور که با یک تست ساده میشه نشون داد. پس شما بعنوان برنامه نویس نباید روی مطابقت ترتیب رکوردها با ترتیب درج اونها حساب کنید.

بعدم شما حساب کن یک جدولی که ترافیک Insert و Delete زیادی روش هست، اگر این کارها رو انجام ندن ممکنه به چه سرعتی حجمش چقدر زیاد بشه. پس ممکنه یک مقدار هزینه برای این کار ارزشش رو داشته باشه.
فرض نکن که همهء کارها مثل نیاز و کاربردهای خودت هست که عملیات Insert و Delete مداوم نداشته باشن. هر رکوردی که حذف میشه اگر رکورد بعدی جاش نیاد یک فضای خالی و هدر رفته میشه. حالا اینا رو میشه با رکوردهای جدید پر کرد و میشه هم هر چندوقت یک بار با یک عملیات یک باره و البته زمانبرتر و سنگین تر بیاد و کل جدول رو دوباره از ابتدا مرتب کنه.
بازم لزوما از یک روش در همه جا و همه شرایطی و هر جور جدول و دیتایی استفاده نمیشه.
  پاسخ
تشکر شده توسط : masoudmanson
#8
چرا دیگه vejmad متوجه منظورت شدم.
میگی که وقتی که داریم ساده روی دیتابیس select می زنیم و از order استفاده نمی کنیم ترتیب هر بار یه جوری هست. و یا اینکه یک فیلدی داریم و روش sort می زنیم. داده های شبیه به هم هر بار ممکنه ترتیبشون فرق کنه مگه منظورت این نیست؟ اگر هست بگو تا توضیحاتمو کامل کنم اگر هم که نیست سعی کن بهم بفهمونی (می دونم کار سختیه Big Grin )
  پاسخ
تشکر شده توسط :
#9
(۱۳۹۱ خرداد ۱۵, ۱۰:۳۰ ب.ظ)admin نوشته: چرا دیگه vejmad متوجه منظورت شدم.
میگی که وقتی که داریم ساده روی دیتابیس select می زنیم و از order استفاده نمی کنیم ترتیب هر بار یه جوری هست. و یا اینکه یک فیلدی داریم و روش sort می زنیم. داده های شبیه به هم هر بار ممکنه ترتیبشون فرق کنه مگه منظورت این نیست؟
تقریبا اون مورد دومی که گفتی.
ببین من در کوئری عادی به این قضیه جابجا شدن رکوردهایی که مقدار فیلد Sort اونا یکی هست برنخوردم. فقط موقعی که دوتا کوئری مربوط به Pagination پشت سرهم بودن این قضیه رو دیدم. یعنی کوئری ها limit و offset داشتن و مربوط به مثلا صفحهء 1 و 2 نتایج میشدن.

ضمنا اشتباه کردم از جدول و دیتایی که این مشکل رو داشت کپی نگرفتم. بعدا هرکاری کردم دیگه اون شرایط درست نشد. هرچی رکورد حذف و درج کردم فایده نداشت که نداشت. روی اون جدول چند بار حذف و درج داشتم و خلاصه شرایطی که منجر به اون رفتار شده بود رو شاید دیگه نشه ایجاد کرد. ممکنه احتمال وقوعش خیلی کم باشه. بهرحال تا جاییکه تست کردم و تشخیص دادم اشکال از کد من نبود. و مثلا اگر روی ستون دیگه Sort میزدم یا ستون دیگری مثل auto رو به order by اضافه میکردم مشکل رفع میشد.

شایدم باگی چیزی بوده! بهرحال همیشه حتی در نرم افزارهای معروف و باسابقه هم امکان باگ وجود داره. ولی خب دیگه میگم اگر مشکل نداره خب auto رو به تمام sort ها اضافه میکنم، چون میترسم این قضیه واقعیتش باشه و ترتیب بتونه تغییر کنه (عمدتا در کوئری های limit و offset پشت سرهم منظورم هست البته).

میگم نکنه یکی از دلایل اینکه نرم افزارهایی مثل فرومها که ظاهرا برای جستجوی کاربر یک کوئری کلی میزنن و نتایج رو موقتا ذخیره میکنن و بعدش از اون نتایج کش شده Pagination میکنن همین باشه! نه؟
بعضی چیزا هست کمتر کسی میدونه و توی منابع خیلی کمی بهشون اشاره شده.
  پاسخ
تشکر شده توسط :
#10
من باید اول از همه ببینم داخل mybb چه جوری بعد بعد بهت میگم. ولی فکر کنم اینها نتیجه رو ذخیره نمی کنن فقط کوئٰری تولید شده رو ذخیره می کنن. چون پارامترهای جستجو زیاد هستن توی صفحه بندی به مشکل بر می خورن. باید برم ببینم تا بعد بگم.
حالا این چیزی که تو میگی رو من خیلی راحت توی pgsql داریم. و میاییم رو روی اون کلید اصلی sort می زنیم ( چون یکتا هست این مشکل پیش نمیاد.) حالا توی مثالی که گفتم فرض کن یه فیلد داری به اسم date و وقتی روش sort می زنی مشکل داری و ترتیب رکوردهایی که مقدار date اونها یکی هست میایی و علاوه بر اینکه روی date سورت می زنی روی فیلد یکتات(به طور مثال اسمش id هست) هم sort می زنی که
کد:
sort date DESC,id DESC


در مورد sort پیشفرض روی myisam هم این قسمت رو بخون
http://dev.mysql.com/doc/refman/5.0/en/alter-table.html
قسمت order by
  پاسخ
تشکر شده توسط :


پرش به انجمن:


کاربران در حال بازدید این موضوع: 1 مهمان