سؤال

النظر في فهرسة الخلية الجدول مع 7 أعمدة ، ويجري باستمرار الاستعلام و كتابة.ما هو المستحسن عدد الصفوف أن هذا الجدول ينبغي أن يسمح لاحتواء قبل الأداء سوف يتحسن عن طريق تقسيم البيانات إلى الجداول ؟

هل كانت مفيدة؟

المحلول

ما إذا كنت سوف تحصل على كسب الأداء عن طريق تقسيم البيانات يعتمد على البيانات و الاستفسارات سوف تعمل على ذلك.يمكنك تخزين العديد من الملايين من الصفوف في الجدول مع الفهارس ومصممة تصميما جيدا الاستفسارات وسوف يكون لا يزال بسرعة فائقة.فقط النظر في التقسيم إذا كنت بالفعل على ثقة من أن المؤشرات و الاستعلامات هي جيدة كما أنها يمكن أن تكون ، كما أنها يمكن أن تكون أكثر صعوبة مما يستحق.

نصائح أخرى

هناك رقم سحري ، ولكن هناك عدد قليل من الأشياء التي تؤثر على الأداء على وجه الخصوص:

  • مؤشر أصل:لا تهتم الفهرسة على التوالي التي لديه 2 أو 3 القيم (مثل التعداد).على طاولة كبيرة ، للمحسن الاستعلام سيتم تجاهل هذه.
  • هناك مفاضلة بين ويكتب والفهارس.أكثر المؤشرات لديك ، يعد يكتب تأخذ.لا مجرد مؤشر كل عمود.تحليل استعلامات انظر الأعمدة التي تحتاج إلى أن تكون مفهرسة على التطبيق الخاص بك.
  • IO القرص و الذاكرة تلعب دورا هاما.إذا كنت يمكن أن يصلح بك الجدول بأكمله في الذاكرة, كنت تأخذ القرص IO من المعادلة (مرة واحدة في الجدول مؤقتا ، على أي حال).تخميني هو أن ما تغير الأداء عند الجدول الخاص بك هو كبير جدا إلى المخزن المؤقت في الذاكرة.
  • النظر في التقسيم الملقمات الخاصة بك على أساس الاستخدام.إذا كان الخاص بك المعاملات نظام القراءة/الكتابة واحدة الصفوف ، ربما يمكنك شراء نفسك بعض الوقت قبل تكرار البيانات إلى قراءة فقط خادم تقديم التقارير المجمعة.

كما تعلمون على الأرجح ، الجدول الأداء التغييرات بناء على حجم البيانات.إبقاء العين على جدول/استعلامات.عليك أن تعرف عندما حان وقت التغيير.

الخلية 5 التقسيم بنيت في هو لطيف جدا.ما هو لطيف هو يمكنك تحديد كيف الجدول الخاص بك يجب أن ننفصل.فعلى سبيل المثال ، إذا كان الاستعلام في الغالب على أساس userid يمكنك تقسيم الجداول الخاصة بك استنادا إلى معرف المستخدم أو إذا كنت الاستعلام عن مواعيد تفعل ذلك التاريخ.ما الجيد في هذا هو أن الخلية سوف تعلم بالضبط أي تقسيم الجدول إلى البحث من خلال العثور على القيم الخاصة بك.الجانب السلبي هو إذا كنت البحث على حقل ليس تحديد القسم الخاص بك الذهاب إلى المسح الضوئي من خلال كل جدول ، والتي يمكن أن تقلل من الأداء.

في حين بعد حقيقة أنك يمكن أن تشير إلى حجم الجدول في الأداء أصبحت مشكلة, أنا لا أعتقد أنك يمكن التنبؤ به ، وبالتأكيد ليس من المعلومات الواردة على موقع على شبكة الإنترنت مثل هذا!

بعض الأسئلة التي قد يكون من المفيد أن تسأل نفسك:

  • هو الأداء حاليا مقبول ؟
  • كيف يتم قياس الأداء - هو هناك مترية ؟
  • كيف يمكننا التعرف على غير مقبول الأداء ؟
  • هل نحن قياس الأداء في أي طريقة قد تسمح لنا أن توقعات هذه المشكلة ؟
  • هم جميع لدينا الاستعلامات باستخدام فعالة المؤشر ؟
  • لدينا محاكاة المتطرفة كميات وأحجام في النظام ؟

باستخدام محرك MyISAM, سوف تصل إلى 2GB الحد الثابت على حجم الجدول إلا إذا قمت بتغيير الإعدادات الافتراضية.

لا من أي وقت مضى تطبيق الأمثل إذا كنت لا أعتقد أنه من اللازم.من الناحية المثالية ينبغي أن يحدده اختبار (كما الآخرين قد ألمحت).

أفقي أو عمودي التقسيم يمكن تحسين الأداء ولكن أيضا تعقيد لك التطبيق.لا تفعل ذلك إلا إذا كنت على يقين من أن كنت في حاجة إليها و أنها سوف تساعد بالتأكيد.

فإن البيانات 2G MyISAM حجم الملف فقط الافتراضي و يمكن تغييرها في الجدول وقت إنشاء (أو في وقت لاحق من قبل تغيير ، لكنه يحتاج إلى إعادة بناء الجدول).فإنه لا ينطبق على محركات أخرى (مثلا ، ك InnoDB).

في الواقع هذا سؤال جيد الأداء.هل قرأت جاي الأنابيب?ليس هناك عدد محدد من الصفوف ولكن هناك صفحة محددة لحجم يقرأ ولا يمكن أن يكون هناك أسباب وجيهة العمودي التقسيم.

تحقق له الكونغ فو عرض وننظر لها من خلال وظيفة له.أنا متأكد من أنك سوف تجد أنه كتب بعض النصائح المفيدة في هذا.

هل تستخدم MyISAM?هل تخطط لتخزين أكثر من بضعة غيغا بايت ؟ احترس من MAX_ROWS و AVG_ROW_LENGTH.

جيريمي Zawodny له ممتازة الكتابة حول كيفية حل هذه المشكلة.

مرخصة بموجب: CC-BY-SA مع الإسناد
لا تنتمي إلى StackOverflow
scroll top