it-swarm.asia

1117 أخطأ كثيرة. حد عمود MySQL على الطاولة

لدي جدول به 1699 عمودًا وعندما أحاول إدراج المزيد من الأعمدة التي أحصل عليها ،

رمز الخطأ: 1117. أعمدة كثيرة جداً

في هذا الجدول لدي 1000 صف فقط. بالنسبة لي أهم شيء هو عدد الأعمدة. هل هناك أي قيود على الطاولة؟ أريد إنشاء 2000 عمود. هل هذا ممكن؟

38
OHLÁLÁ

لماذا تحتاج إلى إنشاء جدول حتى 20 عمودًا ، ناهيك عن 2000 ؟؟؟

يمكن للبيانات الممنوحة وغير المنسقة أن تمنع القيام بعمل JOINs لاسترداد العديد من أعمدة البيانات. ومع ذلك ، إذا كان لديك أكثر من 10 أعمدة ، فيجب عليك التوقف والتفكير في ما سيحدث تحت غطاء المحرك أثناء استرداد البيانات.

إذا كان جدول العمود 2000 يخضع لـ SELECT * FROM ... WHERE ، فستقوم بإنشاء جداول مؤقتة كبيرة أثناء المعالجة ، وجلب الأعمدة غير الضرورية ، وإنشاء العديد من السيناريوهات حيث سيتم دفع حزم الاتصالات ( max_allowed_packet ) إلى حافة الهاوية في كل استفسار.

في أيامي السابقة كمطور ، عملت في شركة في عام 1995 حيث كانت DB2 هي نظام إدارة قواعد البيانات الرئيسية. كان لدى الشركة جدول واحد يحتوي على 270 عمودًا ، وعشرات الفهارس ، ولديها مشكلات في الأداء في استرداد البيانات. اتصلوا بشركة IBM وكان لديهم مستشارون ينظرون في بنية نظامهم ، بما في ذلك هذا الجدول المتآلف. تم إخبار الشركة "إذا لم تقم بتطبيع هذا الجدول في العامين المقبلين ، فسوف تفشل DB2 في الاستعلامات التي تقوم بمعالجة Stage2 (أي استعلامات تتطلب الفرز على أعمدة غير مفهرسة)." قيل هذا لشركة متعددة تريليونات دولار ، لتطبيع جدول 270 عمودًا. كم هو أكثر من ذلك جدول 2000 عمود.

فيما يتعلق بـ mysql ، سيكون عليك التعويض عن هذا التصميم السيئ من خلال تحديد خيارات مماثلة لمعالجة DB2 Stage2. في هذه الحالة ، ستكون هذه الخيارات

يعمل تعديل هذه الإعدادات للتعويض عن وجود العشرات ، ناهيك عن المئات ، من الأعمدة بشكل جيد إذا كان لديك TBs من ذاكرة الوصول العشوائي.

تتضاعف هذه المشكلة هندسيًا إذا كنت تستخدم InnoDB حيث سيتعين عليك التعامل مع MVCC (التحكم في التزامن متعدد) محاولة حماية أطنان من الأعمدة مع كل SELECT و UPDATE و DELETE من خلال عزل المعاملات.

[~ # ~] استنتاج [~ # ~]

لا يوجد بديل أو ضمادة يمكن أن تعوض عن التصميم السيئ. من فضلك ، من أجل سلامتك في المستقبل ، تطبيع هذه الطاولة اليوم !!!

37
RolandoMySQLDBA

أجد صعوبة في تخيل أي شيء يمكن أن يحتوي فيه نموذج البيانات بشكل شرعي على 2000 عمود في جدول تمت تسويته بشكل صحيح.

أظن أنك ربما تقوم بنوع ما من مخطط "ملء الفراغات" المشوه ، حيث تقوم بتخزين جميع أنواع البيانات المختلفة في جدول واحد ، وبدلاً من تقسيم البيانات إلى جداول منفصلة وإجراء علاقات ، لديك العديد من الحقول التي تسجل "نوع" البيانات المخزنة في صف معين ، و 90٪ من حقولك فارغة. حتى ذلك الحين ، ترغب في الحصول على 2000 عمود ... yikes.

الحل لمشكلتك هو إعادة التفكير في نموذج البيانات الخاص بك. إذا كنت تقوم بتخزين كومة كبيرة من بيانات المفتاح/القيمة المرتبطة بسجل معين ، فلماذا لا تصممه بهذه الطريقة؟ شيء مثل:

CREATE TABLE master (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields that really do relate to the
    master records on a 1-to-1 basis>
);

CREATE TABLE sensor_readings (
    id INT PRIMARY KEY AUTO_INCREMENT,
    master_id INT NOT NULL,   -- The id of the record in the
                              -- master table this field belongs to
    sensor_id INT NOT NULL,
    value VARCHAR(255)
);

CREATE TABLE sensors (
    id INT PRIMARY KEY AUTO_INCREMENT,
    <fields relating to sensors>
);

ثم للحصول على جميع إدخالات المستشعر المرتبطة بسجل "رئيسي" معين ، يمكنك فقط SELECT sensor_id,value FROM sensor_readings WHERE master_id=<some master ID>. إذا كنت بحاجة إلى الحصول على بيانات سجل في الجدول master مع جميع بيانات المستشعر لهذا السجل ، يمكنك استخدام صلة:

SELECT master.*,sensor_readings.sensor_id,sensor_readings.value
FROM master INNER JOIN sensor_readings on master.id=sensor_readings.master_id
WHERE master.id=<some ID>

ثم ينضم كذلك إذا كنت بحاجة إلى تفاصيل عن كل جهاز استشعار.

25
womble

إنه نظام قياس يحتوي على 2000 مستشعر

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

على الرغم من أنك لا تصل إلى MySQL الحد الأقصى ، إلا أن أحد العوامل الأخرى المذكورة في الرابط ربما يمنعك من الارتفاع

كما يقترح الآخرون ، يمكنك العمل حول هذا القيد من خلال وجود طاولة فرعية بها id, sensor_id, sensor_value ، أو ببساطة ، يمكنك إنشاء جدول ثانٍ ليحتوي فقط على الأعمدة التي لن تتناسب مع الأول (واستخدام نفس PK)

19
Jack says try topanswers.xyz

MySQL 5.0 Column-Count Limits (التشديد مضاف):

هناك حد ثابت يبلغ 4096 عمودًا لكل جدول ، ولكن الحد الأقصى الفعال قد يكون أقل لجدول معين. يعتمد الحد الدقيق على عدة عوامل تفاعلية.

  • لكل جدول (بغض النظر عن محرك التخزين) حجم صف أقصى يبلغ 65535 بايت. قد تضع محركات التخزين قيودًا إضافية على هذا الحد ، مما يقلل من الحد الأقصى الفعال للصف بحجم.

    يحد الحجم الأقصى للصف من عدد الأعمدة (وربما حجمها) لأن الطول الإجمالي لجميع الأعمدة لا يمكن أن يتجاوز هذا الحجم.

...

قد تفرض محركات التخزين الفردية قيودًا إضافية تحد من عدد أعمدة الجدول. أمثلة:

  • يسمح InnoDB بما يصل إلى 1000 عمود.
15
lg_

أولا المزيد من المشتعلة ، ثم الحل الحقيقي ...

أتفق في الغالب مع النيران التي ألقيت عليك بالفعل.

أنا اختلف مع تطبيع القيمة الرئيسية. الاستفسارات في نهاية المطاف تكون مروعة. أداء أسوأ.

إحدى الطرق "البسيطة" لتجنب المشكلة المباشرة (تحديد عدد الأعمدة) هي "تقسيم البيانات عموديًا". لديك ، على سبيل المثال ، 5 طاولات لكل منها 400 عمود. سيكون لديهم جميعًا نفس المفتاح الأساسي ، باستثناء واحد قد يكون هو AUTO_INCREMENT.

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

هل تقوم بفهرسة أي من القيم؟ هل تريد البحث عنها؟ ربما تبحث في تاريخ؟

إذا كنت بحاجة إلى فهرسة الكثير من الأعمدة - بونت.

إذا كنت بحاجة إلى فهرسة القليل - ضعها في "الجدول الرئيسي.

إليك الحل الحقيقي (إذا كان ينطبق) ...

إذا كنت لا تحتاج إلى مجموعة كبيرة من أجهزة الاستشعار المفهرسة ، فلا تجعل الأعمدة! نعم ، سمعتني. بدلاً من ذلك ، قم بتجميعها في JSON ، وضغط JSON ، وتخزينها في حقل BLOB. ستوفر الكثير من المساحة. سيكون لديك جدول واحد فقط ، مع عدم وجود مشاكل في حدود العمود ؛ سيتم إلغاء ضغط تطبيقك ، ثم استخدام JSON كهيكل. خمين ما؟ يمكن أن يكون لديك هيكل - يمكنك تجميع المستشعرات في صفائف ، أشياء متعددة المستويات ، وما إلى ذلك ، تمامًا كما يريد تطبيقك. "ميزة" أخرى - إنها مفتوحة. إذا قمت بإضافة المزيد من أجهزة الاستشعار ، فلن تحتاج إلى تعديل الجدول. JSON إذا كانت مرنة بهذه الطريقة.

(الضغط اختياري ؛ إذا كانت مجموعة البيانات ضخمة ، فستساعد في مساحة القرص ، وبالتالي الأداء العام.)

7
Rick James

أرى هذا على أنه سيناريو محتمل في عالم البيانات الضخمة ، حيث قد لا تقوم بتنفيذ نوع الاستعلامات التقليدية * من الاستعلامات. نتعامل مع هذا في عالم النمذجة التنبئي على مستوى العميل حيث نقوم بتصميم نموذج عميل عبر آلاف الأبعاد (جميعها ذات قيم 0 أو 1). طريقة التخزين هذه تجعل أنشطة بناء نموذج المصب أسهل عندما تكون لديك عوامل الخطر في نفس الصف وعلامة النتيجة في نفس الصف أيضًا. سيحتاج النموذج التنبئي إلى تحويله مرة أخرى إلى مخطط مسطح. نحن نستخدم redshift الذي يقوم بتخزين عمودي ، وبالتالي يتم تخزين الأعمدة التي يزيد عددها عن 1000 عمود عند تحميل البيانات ، بتنسيق عمودي ...

هناك وقت ومكان لهذا التصميم. إطلاقا. التطبيع ليس الحل لكل مشكلة.

4
BigDataGuy