it-swarm.asia

متى تستخدم TINYINT عبر INT؟

بشكل عام ، أستخدم دائمًا Ints. أعلم أنه من الناحية النظرية ، هذه ليست أفضل ممارسة ، على الرغم من أنك يجب استخدام أصغر نوع من البيانات الذي سيتم ضمانه لتخزين البيانات.

على سبيل المثال ، من الأفضل استخدام tinyint عندما تعلم أن البيانات الوحيدة التي ستقوم بتخزينها هي 1 أو 0 أو فارغة (مع فرصة ضئيلة جدًا لتوسيعها إلى 2 أو 3 لاحقًا).

ومع ذلك ، فإن السبب الوحيد الذي أعرفه للقيام بذلك هو لأغراض التخزين - باستخدام 1 بايت على التوالي بدلاً من 4 بايت.

ما هي آثار استخدام tinyint (أو smallint أو حتى bigint) على int فقط ، بخلاف توفير مساحة على محرك الأقراص الثابتة الخاص بك؟

92
Richard

مساحة القرص رخيصة ... ليست هذه هي النقطة!

توقف عن التفكير من حيث مساحة التخزين ، فكر بدلاً من ذلك في تجمع المخزن المؤقت و عرض نطاق التخزين . في النهاية القصوى ، ذاكرة التخزين المؤقت CPU و عرض النطاق الترددي لناقل الذاكرة . تعد المقالة المرتبطة جزءًا من السلسلة التي تسلط الضوء على المشكلات المتعلقة باختيار المفتاح المتفاوت الرديء (INT vs GUID مقابل GUID التسلسلي) ولكنها تبرز الفرق الذي يمكن أن تحدثه وحدات البايت.

الرسالة الرئيسية هي مسائل التصميم. لن يظهر الفرق في قاعدة بيانات فردية على خادم محدد بشكل مناسب حتى تصل إلى منطقة VLDB ولكن إذا كان بإمكانك حفظ بعض وحدات البايت ، فلماذا لا تفعل ذلك.

أنا أتذكر البيئة الموصوفة في سؤال سابق . أكثر من 400 قاعدة بيانات ، تتراوح في الحجم من 50 ميجا بايت إلى 50 جيجا بايت لكل مثيل SQL. يمكن أن يؤدي مسح بضعة بايتات لكل سجل ، لكل جدول ، لكل قاعدة بيانات عبر تلك البيئة إلى إحداث فرق كبير.

92
Mark Storey-Smith

بالإضافة إلى إجابات أخرى ...

يتم تخزين إدخالات الصفوف والفهرس في صفحات 8 كيلو. لذا فإن مليون صف عند 3 بايت لكل صف ليس 3 ميغابايت على القرص: فهو يؤثر على عدد الصفوف في الصفحة ("كثافة الصفحة").

الأمر نفسه ينطبق على nvarchar على varchar ، smalldatetime to datetime ، int to tinyint etc

تحرير ، يونيو 2013

http://sqlblog.com/blogs/joe_chang/archive/2013/06/16/load-test-manifesto.aspx

تنص هذه المقالة

المعايير المهمة هي الكاردينال ونسبة الصفحة إلى الصف.

لذا ، اختيار نوع البيانات لا يهم

29
gbn

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

أتوقع بالتأكيد أن أجد أن فحص مدخلات الفهرس في صفحات BTREE سيكون أسرع قليلاً مع أنواع البيانات الأصغر. ومع ذلك ، فإن أي VARCHARs المشاركة في إدخالات الفهرس سيعوض (يبطل) مكاسب الأداء من استخدام TINYINT عبر INT.

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

14
RolandoMySQLDBA

تصبح كل الأشياء معقدة التعقيد عندما تصبح قواعد البيانات أكبر:

  • يجب تكبير نوافذ الصيانة أو إعادة جدولتها
  • النسخ الاحتياطية (يصبح النسخ الاحتياطي الكامل في نهاية اليوم آكلاً زمنًا سخيفًا ، لذلك تحتاج إلى نسخ احتياطية مختلفة أو حتى سجل والقيام بكامل مرة واحدة في الأسبوع ، وربما مرة واحدة في الشهر)
  • تصبح صيانة الأداء عبارة عن مرهم للوقت (لا يستغرق إنشاء فهرس على جدول متعدد الملايين من الصفوف وقتًا بسيطًا للتنفيذ) ويحتاج إلى إعادة جدولته ويزداد سوءًا إذا كان الجدول عريضًا ...
  • ونقل تلك النسخة الاحتياطية التي تبلغ 100 جيجابايت عبر الشبكة ليس ما أسميه قطعة من الكعكة - خاصة إذا كانت الشبكة (لسبب غير معروف) عنيدة في قطع الاتصال على علامة 75 جيجابايت ... (حدث مع التثبيت الذي كنت أعمل عليه تم النسخ الاحتياطي إلى محرك أقراص معيّن على الشبكة - الشبكة) ...

وما علاقة أنواع البيانات بهذا؟ كل شيء. استخدام أحجام الصفوف أكبر من اللازم يجعل صفحات قاعدة البيانات تملأ قبل الحاجة أو حتى تضيع مساحة إذا كان حجم الصف هكذا أنه لا يمكن تسجيل أكثر من سجل واحد على الصفحة. والنتيجة هي المزيد من الصفحات المطلوبة للكتابة والقراءة ، المزيد من الذاكرة [RAM تستخدم لتخزين ذاكرة التخزين المؤقت (تحتاج السجلات الأكبر إلى ذاكرة أكبر). ونظرًا لأن أنواع البيانات الخاصة بك يتم تحديدها أكبر مما هو مطلوب من القرص ، فإن الفهارس الخاصة بك ستعاني نفس المشكلة - خاصة إذا قمت بتجميع المفتاح الأساسي المكون من عمودين كبيرين لأن أي فهارس أخرى تم إنشاؤها ستنسخ هذا المفتاح الأساسي بشكل ضمني على تعريفها.

إذا كنت تعلم أن بعض الأعمدة في الجدول التي ستحتوي على ملايين الصفوف أو حتى الجداول الصغيرة التي سيتم تحويلها إلى عدة ملايين من الصفوف التي لا تحتاج إلى 4 بايت لتخزين بياناتها ، ولكن 2 بايت يكفي - استخدم SMALLINT . إذا كانت القيم في النطاق 0-255 كافية ، TINYINT . علم نعم/لا؟ يوجد بت .

13
Fabricio Araujo

بينما لـ tinyint مقابل int هناك اختلافات واضحة مثل مساحة القرص وتقسيم الصفحة ووقت الصيانة ، لن يكون هناك أي من هذه لـ varchar.

فلماذا لا تعلن جميع حقول النص على أنها varchar(4000) ، لأنها ستستهلك على أي حال المساحة المطلوبة فقط؟ والأكثر من ذلك أنك ستضمن عدم اقتطاع بياناتك أبدًا.

الجواب بالطبع:

  1. توضيح نواياك (حيث لن يفهم أحد لماذا يجب أن يكون حقل الاسم 4000 حرف)
  2. التحقق من الصحة كما تريد التأكد من عدم دخول أي سيرة كاملة كاسم.

تنطبق هذه الأسباب نفسها على tinyint أيضًا.

9
yoel halb