این تغییر کد از 25 دقیقه به 23 ثانیه پرس و جوهای MySQL را افزایش داد

در کارهای پردازش دسته منبع JDBC ، اگر table_path وت partition_column پیکربندی شده ، موتور به صورت پویا داده ها را تقسیم می کند. ما می توانیم با تجزیه و تحلیل داده های نمونه ، فواصل پارتیشن را بهینه کنیم تا از مسائل مربوط به داده ها جلوگیری شود. با این حال ، مشاهده شده است که حتی چه زمانی where_condition پیکربندی شده است ، الگوریتم پارتیشن بندی پویا هنوز کل جدول را تقسیم می کند. این منجر به مصرف بیش از حد زمان در مرحله پارتیشن بندی می شود ، به خصوص هنگام بازیابی مقدار کمی از داده ها از یک جدول بزرگ. برای پرداختن به این موضوع ، برای بهینه سازی عملکرد باید فرآیندهای مربوطه را اصلاح کنیم.

تمام اظهارات SQL در توضیحات زیر از MySQL به عنوان نمونه استفاده می کند. منابع داده های مختلف دارای روش های زیر کلاس خاص هستند که از طریق نوشتن رونویسی اجرا می شوند.

تجزیه و تحلیل مشکل کلیدی

  • 55 گیگابایت مورد میز MySQL:

    اجرای اصلی انجام شد 25 دقیقه برای خواندن 1000 ردیف

    نسخه بهینه شده به23 ثانیه (PR #8760)

1.1 فرآیند اصلی پارتیشن بندی داده ها

نقطه ورود برای پارتیشن بندی پویا در کد splitTableIntoChunks روش در DynamicChunkSplitter کلاس. جعبه های روشن شده قرمز در نمودار جریان ، قطعاتی را که نیاز به اصلاح دارند ، نشان می دهد که در زیر فرآیندهای زیر به تفصیل ارائه می شود.

1.1.1 پرس و جو حداقل و حداکثر مقادیر

لازم است که …

Source link