"MySQL সারি আকার খুব বড়" এর সীমা পরিবর্তন করুন

Question

আমি কীভাবে সীমা পরিবর্তন করতে পারি

সারি আকার খুব বড় (> 8126)। পাঠ্য বা বিএলওবিতে কিছু কলাম পরিবর্তন করা বা ব্যবহার ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSEDকরতে সহায়তা করতে পারে। বর্তমান সারির বিন্যাসে, BLOB768 বাইটের উপসর্গটি ইনলাইন সঞ্চিত রয়েছে।

টেবিল:

id  int(11) No       
name    text    No       
date    date    No       
time    time    No       
schedule    int(11) No       
category    int(11) No       
top_a   varchar(255)    No       
top_b   varchar(255)    No       
top_c   varchar(255)    No       
top_d   varchar(255)    No       
top_e   varchar(255)    No       
top_f   varchar(255)    No       
top_g   varchar(255)    No       
top_h   varchar(255)    No       
top_i   varchar(255)    No       
top_j   varchar(255)    No       
top_title_a varchar(255)    No       
top_title_b varchar(255)    No       
top_title_c varchar(255)    No       
top_title_d varchar(255)    No       
top_title_e varchar(255)    No       
top_title_f varchar(255)    No       
top_title_g varchar(255)    No       
top_title_h varchar(255)    No       
top_title_i varchar(255)    No       
top_title_j varchar(255)    No       
top_desc_a  text    No       
top_desc_b  text    No       
top_desc_c  text    No       
top_desc_d  text    No       
top_desc_e  text    No       
top_desc_f  text    No       
top_desc_g  text    No       
top_desc_h  text    No       
top_desc_i  text    No       
top_desc_j  text    No       
status  int(11) No       
admin_id    int(11) No 

Comments

Noপ্রদর্শিত হচ্ছে কি ?

— hjpotter92

ত্রুটিটি আপডেট করতে পারে না "সারি আকার খুব বড় (> 8126) some

— লাসা কার্ট

কমপক্ষে মন্তব্য হিসাবে আপনি কি আপনার পোস্টে আরও কিছু বিশদ যুক্ত করতে পারেন?

— Eineki

যদি এই ডেটা অন্য টেবিলে থাকে তবে পরিবর্তে একটি বিদেশী কী ব্যবহার করার কথা বিবেচনা করুন, এটি আপনার সারি আকারটি নাটকীয়ভাবে হ্রাস করবে এবং আপনার ডাটাবেস স্কিমাটিকে স্বাভাবিক করবে।

— didierc

@ ওল: ওফস, আপনি ঠিক বলেছেন - অন্য একের কাছাকাছি ভোট দিন

— পথিক্রিত

Answer 1

সার্ভারফল্টেও প্রশ্ন জিজ্ঞাসা করা হয়েছে ।

আপনি এই নিবন্ধটি একবার দেখে নিতে চাইতে পারেন যা মাইএসকিউএল সারির আকারগুলি সম্পর্কে অনেক কিছু ব্যাখ্যা করে। এটি লক্ষণীয় গুরুত্বপূর্ণ যে আপনি পাঠ্য বা বিএলওবি ক্ষেত্রগুলি ব্যবহার করার পরেও আপনার সারির আকারটি 8K এর বেশি হতে পারে (InnoDB এর সীমা) কারণ এটি পৃষ্ঠায় প্রতিটি ক্ষেত্রের ইনলাইনটির জন্য প্রথম 768 বাইট সংরক্ষণ করে।

এটি ঠিক করার সহজ উপায় হ'ল ইনোডিবি সহ ব্যারাকুডা ফাইল ফর্ম্যাটটি ব্যবহার করা । এটি মূলত প্রথম 768 বাইট সংরক্ষণের পরিবর্তে পাঠ্য ডেটাতে 20 বাইট পয়েন্টার সংরক্ষণ করে সমস্যা থেকে পুরোপুরি মুক্তি পাবে।

---

ওপিটির জন্য যে পদ্ধতিটি কাজ করেছিল তা হ'ল:

1. বিভাগের my.cnfঅধীনে ফাইলটিতে নিম্নলিখিতগুলি যুক্ত করুন [mysqld]।

   innodb_file_per_table=1
   innodb_file_format = Barracuda

2. ALTERটেবিল ব্যবহার করতে ROW_FORMAT=COMPRESSED।

   ALTER TABLE nombre_tabla
       ENGINE=InnoDB
       ROW_FORMAT=COMPRESSED 
       KEY_BLOCK_SIZE=8;

---

উপরোক্তগুলি এখনও আপনার সমস্যাগুলি সমাধান করে না এমন একটি সম্ভাবনা রয়েছে। এটা একটা হয় পরিচিত (এবং যাচাই) বাগ সঙ্গে InnoDB ইঞ্জিন, এবং এখন জন্য একটি সাময়িক ফিক্স ফলব্যাক হয় MyISAM অস্থায়ী স্টোরেজ হিসাবে ইঞ্জিন। সুতরাং, আপনার my.cnfফাইলটিতে:

internal_tmp_disk_storage_engine=MyISAM

Comments

+1 -> ইনোডাব_ফিল_পিটার_সংশ্লিষ্ট অংশটি অত্যন্ত গুরুত্বপূর্ণ এবং ফর্ম্যাটটি ব্যারাকুডায় পরিবর্তন করে একসাথে চলে যায়। এটি ছাড়া, মাইএসকিউএল নিঃশব্দে অ্যান্টেলোপ ব্যবহার চালিয়ে যাবে।

— নিক

@ এদুয়ার্দো আমি প্রথমে ডেটা ব্যাক আপ করার পরামর্শ দেব। তবে হ্যাঁ, আপনি প্রযোজনায়ও এটি করতে পারেন!

— hjpotter92

innodb_file_per_table=1এই বিকল্পটি সক্রিয় করতে ব্যবহার করুন ।

— স্টিজন গিউকেনস

এটি সমস্যার সমাধানের গ্যারান্টিযুক্ত নয়। এই পোস্টটি উদাহরণস্বরূপ স্ক্রিপ্টের জন্য দেখুন যা এই সেটিংস যুক্ত করে তবে ত্রুটিটি পুনরুত্পাদন করতে সক্ষম।

— সেরিন

@ user1183352 আমার উত্তর উপরে আপডেট করুন। এটিকে আরও গভীরভাবে ডুবিয়ে দেওয়ার জন্য আমাকে আবার স্মরণ করিয়ে দেওয়ার জন্য ধন্যবাদ। :)

— hjpotter92

Answer 2

আমি সম্প্রতি এই সমস্যায় পড়েছি এবং এটি অন্যভাবে সমাধান করেছি। আপনি যদি মাইএসকিউএল সংস্করণ 5.6.20 চালাচ্ছেন তবে সিস্টেমে একটি জ্ঞাত বাগ রয়েছে। মাইএসকিউএল ডক্স দেখুন

গুরুত্বপূর্ণ বাগ # 69477 এর কারণে, পুনরায় লোগো বড়, বহিরাগত সঞ্চিত বিএলওবি ক্ষেত্রগুলির জন্য সাম্প্রতিকতম চেকপয়েন্টটি মুছে ফেলতে পারে writes এই ত্রুটিটি মোকাবেলার জন্য, মাইএসকিউএল 5.6.20 এ প্রবর্তিত একটি প্যাচ পুনরায় লগের আকারকে সীমাবদ্ধ করে BLOB রেডো লগ ফাইলের আকারের 10% এ লেখায়। এই সীমাবদ্ধতার ফলস্বরূপ, ইনোডাব_ব্লগ_ফাইল_সাইজটি আপনার সারণির সারিগুলিতে এবং অন্যান্য ভেরিয়েবল দৈর্ঘ্যের ক্ষেত্রগুলির দৈর্ঘ্য (ভ্যারচারার, ভারবিনারি এবং টেক্সট টাইপ ক্ষেত্রগুলি) পাওয়া সর্বাধিক বিএলএলবি ডেটা আকারের 10 গুণ বেশি মান সেট করা উচিত।

আমার পরিস্থিতিতে আপত্তিজনক ব্লব টেবিলটি প্রায় 16 এমবি ছিল। সুতরাং, আমি যেভাবে সমাধান করেছি তা হ'ল মাই সিএনএফ-তে একটি লাইন যুক্ত করে নিশ্চিত করা হয়েছিল যে আমার কমপক্ষে 10x পরিমাণ ছিল এবং পরে কিছু:

innodb_log_file_size = 256M

Comments

চিহ্নিত করা. longblobআমি innodb_log_file_sizeপ্যারামিটারটি বাড়ানোর সাথে সাথে কোনও ক্ষেত্রে আমার "সারি আকার খুব বড়" ত্রুটি অদৃশ্য হয়ে গেল । এছাড়াও চলমান ছিল 5.6.20।

— অ্যাডামআপ

ধন্যবাদ। ৫..6.২১ এর হোমব্রু চালাচ্ছিল, পরম পরিবর্তন করে সমস্যার সমাধান হয়েছে fixed

— ন্যানোমান

এই এবং @ hjpotter92 এর উত্তর উভয়েরই আমার জন্য এই ত্রুটিটি ঠিক করার প্রয়োজন ছিল।

— সেরিন

ধন্যবাদ। 5.6.21 চলছিল এবং এই সমাধানটি সহায়তা করেছিল।

— পেটিয়ার

এটি আমার সমস্যারও সমাধান করেনি। আমি অনুরূপ থ্রেডে দেখেছি বলে আমার অনেক ভিউচারার ক্ষেত্রকে টেক্সটগুলিতে প্রতিস্থাপনের বিষয়টি বিবেচনা করছি।

— পিডোরিয়া

Answer 3

আপনার my.cnf ফাইলে অনুসরণ করুন এবং মাইএসকিএল সার্ভার পুনরায় চালু করুন।

innodb_strict_mode=0

Comments

innodb_strict_mode=0-> কোনও স্থান নেই। অন্যথায়, mariaDB পুনরায় চালু করার 10.2 ফলাফল ত্রুটি :-P মধ্যে

— Pathros

আমি মারিয়াডবি দিয়ে চেষ্টা করিনি, মাইএসকিউএল এর জন্য স্পেসগুলি অপসারণ করার দরকার নেই।

— কার্ল

ডকুমেন্টেশন অনুসারে, কঠোর মোডটি অক্ষম করা কেবল এরো এবং সতর্কতাগুলি উপস্থিত হতে বাধা দেয়, সুতরাং এটি সমস্যার সমাধান বলে মনে হয় না! ডাউনলোড.

— nust.na/pub6/mysql/doc/innodb-plugin/1.1/en/…

এটি কাজ করছে বলে মনে হচ্ছে এবং আমাকে ইস্যু এবং ডেটা সঞ্চয় ছাড়াই টেবিলগুলি তৈরি করতে দাও

— ক্রিস মুইঞ্চ

@ জোওও

— কার্ল

Answer 4

আপনি যদি ইঞ্জিন স্যুইচ করতে পারেন এবং InnoDB এর পরিবর্তে মাইআইএসএএম ব্যবহার করতে পারেন তবে এটির সহায়তা করা উচিত:

ENGINE=MyISAM

মাইআইএসএএম এর সাথে দুটি সতর্কতা রয়েছে (তর্কাতীতভাবে আরও):

1. আপনি লেনদেন ব্যবহার করতে পারবেন না।
2. আপনি বিদেশী কী সীমাবদ্ধতা ব্যবহার করতে পারবেন না।

Comments

লেনদেন এবং বিদেশী কী সীমাবদ্ধতা ছাড়াই আপনার আপত্তি না থাকলে ভাল। তবে সচেতন থাকুন যে মাইআইএসএএম-এ স্যুইচ করার সময় আপনি এগুলি আলগা করেন।

— wobbily_col

এই পরামর্শটি পাগল - অন্তত বাক্যাংশটি এটি সাবধান করে দেবে! লেনদেন এবং foregith কী সীমাবদ্ধতা এই ফর্ম্যাট সঙ্গে সমস্যা সর্বনিম্ন!

— হাসান সৈয়দ

দুঃখিত এই উত্তরটি হ্রাস পেয়েছে। জড়িত সমস্ত ক্যাভেট উল্লেখ করার জন্য দয়া করে আপডেট করুন। এই পরামর্শ অনুসরণ করে যে কেউ কেবল এমন কোনও ফর্ম্যাটে স্যুইচ করে যা আমি কোনও উত্পাদন ব্যবস্থায় কখনও ব্যবহার করব না।

— রিমকো ওয়েেন্ড

এবং মাইআইএসএএম চলে যাচ্ছে।

— রিক জেমস

আমার জন্য কাজ। আমার ক্ষেত্রে আমার প্রতিটির দৈর্ঘ্যে প্রায় 300 টিরও বেশি ক্ষেত্র ছিল। এই টেবিলটিতে আমার কোনও সম্পর্ক নেই তাই মাইআইএসএএম এ স্যুইচ করা ঠিক হয়েছিল।

— রবার্ট সায়লর

Answer 5

আমি একটি দুর্দান্ত উত্তর ভাগ করতে চাই, এটি সহায়ক হতে পারে। ক্রেডিট বিল কারভিন এখানে দেখুন /dba/6598/innodb-create-table-error-row-size-too-large

এগুলি ইনোডিবি ফাইল ফর্ম্যাট অনুসারে পরিবর্তিত হয় present বর্তমানে এন্টেলোপ এবং ব্যারাকুডা নামে দুটি ফর্ম্যাট রয়েছে।

কেন্দ্রীয় টেবিল স্পেস ফাইল (আইবডাটা 1) সবসময় অ্যান্টেলোপ ফর্ম্যাটে থাকে। আপনি যদি প্রতি টেবিলে ফাইল ব্যবহার করেন তবে আপনি পৃথক ফাইলগুলি মাই সিএনএফ-এ ইনোডাব_ফিল_ফর্ম্যাট = বারাকুডা সেট করে ব্যারাকুডা ফর্ম্যাটটি ব্যবহার করতে পারেন।

বেসিক পয়েন্টস:

1. ইনোডিবি ডেটার একটি 16 কেবি পৃষ্ঠায় অবশ্যই কমপক্ষে দুটি সারি ডেটা রাখা উচিত। প্লাস প্রতিটি পৃষ্ঠায় পৃষ্ঠা শেকসসাম এবং লগ সিকোয়েন্স নম্বর এবং এর মতো একটি শিরোনাম এবং একটি পাদচরণ রয়েছে। সেখানেই আপনি সারি প্রতি 8KB এর থেকে কিছুটা কম সীমা পেয়ে যান।

2. INTEGER, তারিখ, ফ্লাট, CHAR- এর মতো স্থির আকারের ডেটাগুলি এই প্রাথমিক ডেটা পৃষ্ঠায় সংরক্ষণ করা হয় এবং সারি আকারের সীমাতে গণনা করা হয়।

3. ভেরিয়েবল-আকারের ডেটা ধরণের মতো ভ্রচার, পাঠ্য, বিএলওবি ওভারফ্লো পৃষ্ঠায় সংরক্ষণ করা হয়, তাই তারা সারি আকারের সীমাতে পুরোপুরি গণনা করে না। অ্যান্টেলোপে, ওভারফ্লো পৃষ্ঠায় সঞ্চিত হওয়ার পাশাপাশি এ জাতীয় কলামগুলির 768 বাইট অবধি প্রাথমিক তথ্য পৃষ্ঠায় সংরক্ষণ করা হয়। ব্যারাকুদা একটি গতিশীল সারি বিন্যাস সমর্থন করে, তাই এটি প্রাথমিক ডেটা পৃষ্ঠায় কেবলমাত্র 20-বাইট পয়েন্টার সঞ্চয় করতে পারে।

4. দৈর্ঘ্যটি এনকোড করার জন্য ভেরিয়েবল-আকারের ডেটা প্রকারগুলি 1 বা আরও বেশি বাইট সহ উপসর্গযুক্ত হয়। এবং InnoDB সারি বিন্যাসে ফিল্ড অফসেটগুলির একটি অ্যারেও রয়েছে। সুতরাং তাদের উইকিতে কমবেশি নথিভুক্ত একটি অভ্যন্তরীণ কাঠামো রয়েছে।

ওভারফ্লো ডেটার জন্য আরও স্টোরেজ দক্ষতা অর্জন করতে বারাকুডা একটি ROW_FORMAT = সংক্ষেপিত সমর্থন করে।

আমার আরও মন্তব্য করতে হবে যে আমি কখনই একটি সুনির্দিষ্টভাবে নকশাযুক্ত টেবিলটি সারি আকারের সীমা ছাড়িয়ে দেখিনি। এটি একটি শক্তিশালী "কোড গন্ধ" যা আপনি প্রথম সাধারণ ফর্মটির পুনরাবৃত্তি গোষ্ঠীগুলির শর্ত লঙ্ঘন করছেন।

Answer 6

আমার একই সমস্যা ছিল, এটি আমার জন্য এটি সমাধান করেছে:

ALTER TABLE `my_table` ROW_FORMAT=DYNAMIC;

এমওয়াইএসকিউএল ডকুমেন্টেশন থেকে :

DYNAMIC সারি বিন্যাসটি সূচক নোডে পুরো সারিটি সংরক্ষণ করার দক্ষতা বজায় রাখে যদি এটি ফিট হয় (যেমন চুক্তি এবং পুনর্নির্মাণ ফর্ম্যাটগুলি করা হয়) তবে এই নতুন ফর্ম্যাটটি বি-ট্রি নোডের বিশাল সংখ্যক ডেটা বাইটের সাথে পূরণ করার সমস্যাটিকে এড়িয়ে চলে দীর্ঘ কলাম। DYNAMIC ফর্ম্যাটটি এই ধারণার উপর ভিত্তি করে তৈরি করা হয় যে কোনও লম্বা ডেটা মানের একটি অংশ যদি অফ-পৃষ্ঠায় সঞ্চিত থাকে তবে সাধারণত সমস্ত মান অফ-পৃষ্ঠাতে সঞ্চয় করা সবচেয়ে কার্যকর। DYNAMIC ফর্ম্যাট সহ, সংক্ষিপ্ত কলামগুলি বি-ট্রি নোডে থাকতে পারে, যে কোনও প্রদত্ত সারির জন্য প্রয়োজনীয় ওভারফ্লো পৃষ্ঠার সংখ্যা হ্রাস করে।

Comments

... তবে আপনার আলাদা ফাইল ফর্ম্যাট থাকা দরকার তাই আপনি ইতিমধ্যে ব্যারাকুডায় রয়েছেন? কারণ হিসাবে এই আদেশটি চেষ্টা করার সময় আমি একটি ত্রুটি পেয়েছি, বলছিWarnings from last query: InnoDB: ROW_FORMAT=DYNAMIC requires innodb_file_format > Antelope

— টেড

যখন আমি হেইডিএসকিউএলকে তার বিল্ট-ইন জিইউআইয়ের মাধ্যমে একই কমান্ডটি চালাতে দিয়েছি, এটি কোনওভাবে সফল হয়েছিল, তবে এটি কোনও লাভই করতে পারেনি, আমি একই ত্রুটি পেয়েছি,Row size too large (>8126)

— টেড

আমার ইনডাই-তে ইনোডাব_ফিল_ফর্ম্যাট = ব্যারাকুডা সেট করার চেষ্টা করুন এবং টেবিল my_tableROW_FORMAT = ডায়ামিকের চেষ্টা করুন ; আবার

— মাল্টিমিডিয়াপ্লেক্স

হ্যাঁ, আমি মনে করি আসলে আমি শেষ পর্যন্ত কী করেছি এবং আমি মনে করি এটি সমাধান করেছে। তবে হতাশায় একই সময়ে আমি অনেকগুলি কলামও TEXT এ পরিবর্তন করেছি =) যদিও আমি আসলে মনে করি এটি ছিল।

— টেড

ভাল !, আপনি যদি মনে করেন এটি একটি ভাল উত্তর, এটি একটি আপ দিন এবং বৈধ প্রতিক্রিয়া হিসাবে গ্রহণ করুন, ধন্যবাদ!

— মাল্টিমিডিয়াপেক্স

Answer 7

ঘন্টা ব্যয় করার পরে আমি সমাধানটি খুঁজে পেয়েছি: টেবিলটি মাইআইএসএমে রূপান্তর করতে কেবল আপনার মাইএসকিউএল অ্যাডমিনে নিম্নলিখিত এসকিউএল চালান:

USE db_name;
ALTER TABLE table_name ENGINE=MYISAM;

Comments

তৈরির সারণী বিবৃতিতে সমস্যাটি ঘটতে থাকলে খুব বেশি সহায়তা করে না।

— মার্ক ফ্রেজার

create tableএকই বিকল্প রয়েছে:CREATE TABLE ... ENGINE=MyISAM ...

— xebeche

Answer 8

আমি যখন অন্য সার্ভার থেকে ব্যাক আপ করা মাইএসকিএল ডাটাবেস পুনরুদ্ধার করার চেষ্টা করছিলাম তখন আমি এই সমস্যাটিতে ছুটলাম। আমার সমস্যার সমাধানটি আমার মাইকাফের উপর কিছু সেটিংস যুক্ত করছিল (উপরের প্রশ্নগুলির মতো) এবং অতিরিক্ত এসকিউএল ব্যাকআপ ফাইলটি পরিবর্তন করছিল:

পদক্ষেপ 1: my.conf এ নিম্নলিখিত লাইনগুলি যুক্ত বা সম্পাদনা করুন:

innodb_page_size=32K
innodb_file_format=Barracuda
innodb_file_per_table=1

পদক্ষেপ 2 সারণীতে ROW_FORMAT = DYNAMIC যুক্ত করুন যাতে এই ত্রুটির কারণ হয়ে উঠছে এমন টেবিলের জন্য বর্গ ব্যাকআপ ফাইলে বিবৃতি তৈরি করুন:

DROP TABLE IF EXISTS `problematic_table`;
/*!40101 SET @saved_cs_client = @@character_set_client */;
/*!40101 SET character_set_client = utf8 */;
CREATE TABLE `problematic_table` (
`id` bigint(20) NOT NULL AUTO_INCREMENT,
  ...
PRIMARY KEY (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=3 ROW_FORMAT=DYNAMIC;

উপরের গুরুত্বপূর্ণ পরিবর্তনটি হ'ল ROW_FORMAT = DYNAMIC;(এটি অরিজেনাল এসকিএল ব্যাকআপ ফাইলে অন্তর্ভুক্ত ছিল না)

উত্স যা আমাকে এই সমস্যাটি সমাধান করতে সহায়তা করেছে: মারিয়াডিবি এবং ইনোডিবি মাইএসকিউএল সারি আকার খুব বড়

Comments

পদক্ষেপ 1 এ বর্ণিত লাইনের কোনও স্থান থাকা উচিত নয়। লাইন innodb_page_size=32Kকাজ করে না, যেহেতু এটি আমার ক্ষেত্রে মারিয়াডিবি 10.2 পুনরায় চালু করতে ত্রুটি সৃষ্টি করেছিল। পরিবর্তে, আমি এখানেinnodb_strict_mode=0 বর্ণিত হিসাবে লাইন যুক্ত করেছি

— প্যাথ্রোস

প্যাথ্রোস প্রতিক্রিয়া দেওয়ার জন্য আপনাকে ধন্যবাদ, আমি আমার উত্তর আপডেট করেছি এবং পদক্ষেপ 1 থেকে স্থানগুলি সরিয়েছি।

— ম্যাটিয়াস

মাইএসকিউএল এর জন্য নোট <= 5.7.5: 32 কে ইনোডাব_পেজ_সাইজের জন্য বৈধ বিকল্প নয়। দেখুন: dev.mysql.com/doc/refman/5.6/en/…

— ডাব নাজার

এছাড়াও, আপনার অবশ্যই আপনার পুরো মাইএসকিএল সার্ভারটিকে স্ক্র্যাচের জন্য পুনরায় তৈরি করতে হবে, কারণ পরিবর্তনের innodb_page_sizeজন্য ibdata*বিনোদনের প্রয়োজন , যা ধ্বংসাত্মক অপারেশন। আরও তথ্যের জন্য আপনার

— সিসলগ

Answer 9

অন্যান্য উত্তরগুলি জিজ্ঞাসিত প্রশ্নের ঠিকানা। আমি অন্তর্নিহিত কারণটির সমাধান করব: স্কিমা ডিজাইনটি খারাপ নয়।

কলামগুলি জুড়ে কোনও অ্যারে স্প্লে করবেন না। এখানে আপনার কাছে 3 * 10 কলাম রয়েছে যা একটি নতুন টেবিলের 3 টি কলামের 10 সারিতে পরিবর্তিত হওয়া উচিত (প্লাস id, ইত্যাদি)

আপনার Mainটেবিলটি কেবল আছে

id  int(11) No       
name    text    No       
date    date    No       
time    time    No       
schedule    int(11) No       
category    int(11) No       
status  int(11) No       
admin_id    int(11) No 

আপনার অতিরিক্ত টেবিল ( Top) থাকত

id  int(11) No          -- for joining to Main
seq TINYINT UNSIGNED    -- containing 1..10
img   varchar(255)    No       
title varchar(255)    No       
desc  text    No    
PRIMARY KEY(id, seq)    -- so you can easily find the 10 top_titles

Topপ্রতিটি জন্য 10 (বা কম? বা আরও?) সারি থাকবে?id ।

এটি আপনার আসল সমস্যাটি দূর করে এবং স্কিমা পরিষ্কার করে। (এটি "সাধারণীকরণ" নয়, কিছু মন্তব্যে বিতর্কিত))

মাইআইএসএএম এ স্যুইচ করবেন না ; এটা চলে যাচ্ছে।
চিন্তা করবেন না ROW_FORMAT।

JOINএকাধিক কলামের পরিবর্তে একাধিক সারি হ্যান্ডেল করার জন্য আপনাকে আপনার কোডটি পরিবর্তন করতে হবে ।

Answer 10

আমি এডাব্লুএস আরডিএসে মাইএসকিউএল 5.6 ব্যবহার করছি। আমি প্যারামিটার গ্রুপে নিম্নলিখিত আপডেট।

innodb_file_per_table=1
innodb_file_format = Barracuda

পরামিতি গোষ্ঠী পরিবর্তনগুলি কার্যকর হওয়ার জন্য আমাকে ডিবি পুনরায় বুট করতে হয়েছিল।

এছাড়াও, ROW_FORMAT = COMPPressED সমর্থিত ছিল না। আমি নীচের হিসাবে ডায়ামিক ব্যবহার করেছি এবং এটি দুর্দান্ত কাজ করেছে।

ALTER TABLE nombre_tabla ENGINE=InnoDB ROW_FORMAT=DYNAMIC KEY_BLOCK_SIZE=8

Answer 11

ইনোডিবি টেবিলের সর্বাধিক সারি আকার, যা স্থানীয়ভাবে একটি ডাটাবেস পৃষ্ঠায় সঞ্চিত ডেটাতে প্রযোজ্য , 4KB, 8KB, 16KB, এবং 32KB এর অর্ধেক পৃষ্ঠার চেয়ে কিছুটা কম

16 কেবি পৃষ্ঠার (ডিফল্ট) জন্য, আমরা গণনা করতে পারি:

Slightly less than half a page 8126 / Number of bytes to threshold for overflow 767 = 10.59 fields of 767 bytes maximum

মূলত, আপনি এটির সাথে একটি সারি সর্বাধিক বের করতে পারেন:

• 11 বর্ণের ক্ষেত্র> 767 টি অক্ষর (ল্যাটিন 1 = প্রতি বাইট প্রতি বাইট) বা
• 11 বর্ণের ক্ষেত্রগুলি> 255 টি অক্ষর (ইউএসএফসিএল -8 8 প্রতি চারকে 3 বাইট)।

মনে রাখবেন, ক্ষেত্রটি> 767 বাইট হলে এটি কেবল একটি ওভারফ্লো পৃষ্ঠাতে প্রবাহিত হবে। যদি 767 বাইটের অনেকগুলি ক্ষেত্র থাকে তবে এটি আবদ্ধ হবে (সর্বাধিক সারি_সেসকে ছাড়িয়ে যাবে)। ল্যাটিন 1 এর সাথে সাধারণত নয় তবে বিকাশকারীরা যদি সতর্ক না হন তবে utf-8 দিয়ে খুব সম্ভব।

এই ক্ষেত্রে, আমি মনে করি আপনি সম্ভবত ইনোডাব_পৃষ্ঠা_সাইজটিকে 32 কেবি টুকরো টুকরো টানতে পারেন।

my.cnf- এ:

innodb_page_size=32K

তথ্যসূত্র:

• https://dev.mysql.com/doc/refman/8.0/en/column-count-limit.html#row-size-limits
• https://medium.com/@adamhooper/in-mysql-never-use-utf8-use-utf8mb4-11761243e434
• https://mariadb.com/kb/en/library/innodb-compact-row-format/#overflow-pages-with-the-compact-row-format
• ইনোডব পৃষ্ঠার আকার সেটিং

Answer 12

আমিও একই সমস্যার মুখোমুখি হয়েছি। আমি নিম্নলিখিত স্ক্যুএল সম্পাদন করে সমস্যাটি সমাধান করি:

ALTER ${table} ROW_FORMAT=COMPRESSED;

তবে, আমি মনে করি আপনার সারি সঞ্চয়স্থান সম্পর্কে জানা উচিত ।
এখানে দুটি ধরণের কলাম রয়েছে: ভেরিয়েবল-দৈর্ঘ্যের কলাম (যেমন ভ্রচার, ভারবিনারি, এবং বিএলওবি এবং পাঠ্য প্রকারের) এবং স্থির দৈর্ঘ্যের কলাম । এগুলি বিভিন্ন ধরণের পৃষ্ঠায় সঞ্চিত থাকে।

পরিবর্তনীয় দৈর্ঘ্যের কলামগুলি এই নিয়মের ব্যতিক্রম। বি-লে-পৃষ্ঠায় মানানসই দীর্ঘ, যেমন বিএলওবি এবং ভিউচারার কলামগুলি ওভারফ্লো পৃষ্ঠা হিসাবে পৃথকভাবে বরাদ্দ হওয়া ডিস্ক পৃষ্ঠায় সংরক্ষণ করা হয়। আমরা এই জাতীয় কলামগুলিকে অফ-পৃষ্ঠা কলামগুলি বলি। এই কলামগুলির মানগুলি ওভারফ্লো পৃষ্ঠাগুলির একক-লিঙ্কযুক্ত তালিকায় সংরক্ষণ করা হয় এবং এ জাতীয় প্রতিটি কলামের নিজস্ব এক বা একাধিক ওভারফ্লো পৃষ্ঠার তালিকা থাকে। কিছু ক্ষেত্রে, স্টোরেজ নষ্ট করা এবং পৃথক পৃষ্ঠা পড়ার প্রয়োজনীয়তা এড়াতে দীর্ঘ কলাম মানটির সমস্ত বা একটি উপসর্গ বি-ট্রিতে সংরক্ষণ করা হয়।

এবং যখন ROW_FORMAT সেট করার উদ্দেশ্য হয়

যখন ROW_FORMAT = DYNAMIC বা ROW_FORMAT = সংক্ষেপিত একটি সারণী তৈরি করা হয়, তখন InnoDB সম্পূর্ণ ভেরিয়েবল-দৈর্ঘ্যের কলাম মানগুলি (VARCHAR, VARBINARY, এবং BLOB এবং TEXT প্রকারের জন্য) পুরোপুরি অফ-পৃষ্ঠাতে সংরক্ষণ করতে পারে, যেখানে ক্লাস্টারড সূচক রেকর্ডে কেবল একটি 20- থাকে ওভারফ্লো পৃষ্ঠায় বাইট পয়েন্টার।

DYNAMIC এবং সংক্ষেপিত সারি ফর্ম্যাটগুলি সম্পর্কে আরও জানতে চান

Answer 13

এটি যদি অনেকগুলি কলাম সহ একটি নির্বাচন করে থাকে, কারণটি হতে পারে যে মাইএসকিএল একটি অস্থায়ী সারণী তৈরি করছে। যদি এই টেবিলটি মেমরির সাথে ফিট করার জন্য খুব বড় হয় তবে এটি এটির ডিস্কে সঞ্চয় করার জন্য এটির ডিফল্ট টেম্প টেবিল বিন্যাসটি, যা InnoDB ব্যবহার করবে। এই ক্ষেত্রে InnoDB আকার সীমা প্রযোজ্য।

তারপরে আপনার কাছে 4 টি বিকল্প রয়েছে:

1. অন্য পোস্টে বর্ণিত মত ইনডোডব সারির আকার সীমা পরিবর্তন করুন, যার জন্য সার্ভারের পুনর্নির্মাণের প্রয়োজন।
2. কম কলামগুলি অন্তর্ভুক্ত করতে বা আপনার অস্থায়ী টেবিল তৈরি করার কারণ এড়াতে আপনার জিজ্ঞাসাটি পরিবর্তন করুন (অর্থাত্ আদেশগুলি সীমাবদ্ধ করে সীমাবদ্ধ করে)।
3. সর্বোচ্চ_চাপ_সামগ্রী_ আকার পরিবর্তন করে বড় হতে পারে ফলে ফলাফলটি মেমরির সাথে খাপ খায় এবং ডিস্কে লেখার দরকার পড়ে না।

4. ডিফল্ট টেম্প টেবিল ফর্ম্যাটটি মাইআইএসএএম-তে পরিবর্তন করুন, আমি এটি করেছি। My.cnf এ পরিবর্তন করুন:

   internal_tmp_disk_storage_engine=MYISAM

মাইএসকিএল পুনরায় চালু করুন, ক্যোয়ারী কাজ করে।

Answer 14

আগ্রহী প্রত্যেকের জন্য এখানে সহজ পরামর্শ:

10.3.17-মারিয়াডিবি দিয়ে ডেবিয়ান 9 থেকে ডেবিয়ান 10 এ আপগ্রেড করার পরে আমার জুমলা ডাটাবেসগুলি থেকে কিছু ত্রুটি রয়েছে:

[সতর্কতা] InnoDB: fieldসারণীতে ক্ষেত্র যোগ করতে পারে না database।tableকারণ এটি যুক্ত করার পরে, সারিটির আকার 8742 যা সূচক পাতার পৃষ্ঠায় রেকর্ডের জন্য সর্বাধিক অনুমোদিত আকারের (8126) এর চেয়ে বেশি।

সেক্ষেত্রে আমি /etc/mysql/mariadb.conf.d/50-server.cnf এ ইনোডাব_ডিফোল্ট_রো_ ফর্ম্যাট = ডিওয়াইএনমিক সেট করেছি (এটি যাইহোক ডিফল্ট ছিল)

জুমলা ডাটাবেসে সমস্ত টেবিলের জন্য "অপ্টিমাইজ টেবিল" চালানোর জন্য আমি phpmyadmin ব্যবহার করেছি। আমি মনে করি প্রক্রিয়া phpmyadmin দ্বারা টেবিল বিনোদন সাহায্য করেছে। যদি আপনি phpmyadmin ইনস্টল করে থাকেন তবে এটি করার জন্য খুব কম ক্লিক রয়েছে।

Comments

আপনি যদি জুমলা ব্যবহারকারী হন তবে জুমলা স্ট্যাক এক্সচেঞ্জে আমাদের সাথে যোগ দিন - আমরা সর্বদা নতুন অবদানকারীদের ব্যবহার করতে পারি।

— মিকম্যাকুসা