উত্তর:
সাধারণভাবে, আপনার কাছে যত কিছু আছে তার কার্যকারিতা হ্রাস পাবে। তবে, 200 মোটামুটি ছোট সংখ্যার মতো বলে মনে হচ্ছে। 2,000 একটি বাস্তব পারফরম্যান্স হিট এবং অবশ্যই 20,000 হতে পারে। যদিও সাধারণভাবে, আপনার নিজের টেবিলের সংখ্যা ছোট রাখতে হবে যেহেতু মাইএসকিউএল টেবিলে খুব বড় সংখ্যক সারি পরিচালনা করতে পারে।
সারণীর সংখ্যা এতটা গুরুত্ব দেয় না:
অতিরিক্ত টেবিল থাকার অর্থ মেমরি এবং হার্ড ড্রাইভের জায়গা যা আবার ফিরে পাওয়া যায় এবং অন্যান্য জিনিসের জন্য ব্যবহার করা যায়। মনে রাখবেন যে আপনার টেবিলগুলি অস্বীকার করা খারাপ ডেটার ঝুঁকি বাড়ায় কারণ আপনি রেফারেন্সিয়াল অখণ্ডতা থেকে মুক্তি পাচ্ছেন rid
সাধারণভাবে 200 টি সারণী কোনও সমস্যা হওয়া উচিত নয় তবে এটি বেশ কয়েকটি বিষয়ের উপর নির্ভর করে।
ডেডিকেটেড মাইএসকিউএল সার্ভার বনাম সার্ভার অন্যান্য সফ্টওয়্যার, 128 এমবি বনাম 128 গিগাবাইট র্যাম ইত্যাদির সাথে ভাগ করেছে, কয়েকটি রেকর্ডের সাথে ছোট টেবিলগুলি ব্লবগুলি এবং কয়েক মিলিয়ন সারিগুলির সাথে টেবিল বনাম।
মাইএসকিউএলে প্রতিটি সেটিং টেবিলের কার্যকারিতা বিভিন্ন উপায়ে সেটিংস এবং একাধিক ইঞ্জিন থাকতে পারে।
মাইআইএসএএম এর প্রতি টেবিল .frm, .MYD, .MYI প্রতি সাধারণত তিনটি ফাইল থাকে
সাধারণ মোডে INNODB এর কেন্দ্রীয় ফাইলে সঞ্চিত সমস্ত ডেটা সহ .frm রয়েছে
টেবিল মোডে একটি ফাইলের INNODB এর .frm, .idb রয়েছে
টেবিল_পেন_ক্যাচ হ'ল টেবিলের সংখ্যা যা একবারে খোলা যায় (ডিফল্ট 64)। এটি আপনার স্কিমাতে সারণীর সংখ্যার চেয়ে বড় হতে পারে কারণ এটি কত সংযোগ ডিবি কে জিজ্ঞাসা করছে। 100 টি সংযোগ 3 টি টেবিলের সাথে যুক্ত হতে পারে আপনার কাছে 300 টি টেবিল ক্যাশেড এবং কোনও অস্থায়ী টেবিল রয়েছে। সাধারণত আরও জটিল একটি স্কিমা বা সংযোগ বৃহত্তর সংখ্যা।
ওপেন-ফাইলস-সীমা আমি এটি 4x টেবিল_পেন_ক্যাচে সেট করার ঝোঁক রাখি যা একটি সঠিক মান খুঁজে বের করার জন্য বিরক্ত করার চেয়ে উদার হওয়া উচিত।
মাইএসকিএল ব্যবহারকারীর জন্য অপারেটিং সিস্টেমগুলির ফাইল হ্যান্ডেল সীমাটিও একটি সমস্যা হতে পারে (লিনাক্সে ডিফল্টটি প্রায়শই 1024 হতে পারে, ব্যবহারকারীর সীমা দেখানোর জন্য উলামিট করতে পারে) এটি সংখ্যার চেয়ে কম টেবিলের সাথে সমস্যা তৈরি করতে পারে যখন সংখ্যাটি কম থাকে mysql প্রয়োজন। এটি কমপক্ষে ওপেন-ফাইল-সীমা হিসাবে একই হওয়া উচিত।
কোনও ডাটাবেসের মতোই এখানে কয়েকশো টিউনিং প্যারামিটার রয়েছে যা আপনি আপনার নির্দিষ্ট স্কিমার জন্য ডাটাবেসটিকে অনুকূল করতে সমন্বয় করতে পারেন। আপনি যদি এনডিবি ক্লাস্টার ইঞ্জিন চান তবে অতিরিক্ত ইঞ্জিনগুলি প্লাগ করতে পারেন মাইএসকিউএল এটির চেয়ে সবচেয়ে খারাপ।
http://dev.mysql.com/doc/refman/5.1/en/table-cache.html
আশা করি এটা সাহায্য করবে
প্রতিটি টেবিলের সূচকের জন্য মাইএসকিউএল এর নিজস্ব সূচক রয়েছে। সূচক ধরে রাখতে এবং ব্যবহার করতে মেমরি লাগে এবং সূচকের জন্য বিশ্বব্যাপী সীমা রয়েছে। যখন অনেকগুলি টেবিল থাকে সূচিগুলি সমস্ত র্যামে থাকতে পারে না, তাই তারা ডিস্কে যায় যা সরাসরি পারফরম্যান্সকে প্রভাবিত করে। এই উত্থাপন করার চেষ্টা করুন my.cnf: key_buffer_size=256M: এই সূচক তথ্য অধিষ্ঠিত জন্য একপাশে সরিয়ে রাখা RAM এর পরিমাণ।
পারি এটা? অবশ্যই। তবে আপনার অ্যাপ্লিকেশন এবং এটির অ্যাক্সেসের ধরণগুলির উপর এবং আপনি যদি মাইসাম বা ইনোডাব ব্যবহার করছেন এবং যদি ইনোডাবটি ফাইল-প্রতি-টেবিল মোডে রয়েছে এবং ইনডোডব লগের আকার কতটা নির্ভর করে। তার চেয়ে আপনার আরও বিশদ আমাদের দিতে হবে।
না - আমি মনে করি না যে সারণীর সংখ্যাটি আপনার সিস্টেমে পারফরম্যান্সের বাধা হয়ে দাঁড়াবে। সর্বোপরি, এগুলি আপনার ফাইল সিস্টেমে কেবল ফাইল। একটি ডাটাবেসে শত শত টেবিল থাকার বিষয়ে অস্বাভাবিক কিছু নেই।
এর চেয়ে বেশি সম্ভবত আপনার প্রশ্নগুলি সঠিকভাবে অনুকূলিত হয় নি are আমি log-slow-queriesএবং চালু করার পরামর্শ দেব log-queries-not-using-indexes। আপনি যখন ধীর explainঅনুসন্ধানগুলি শনাক্ত করেন, সূচিগুলি অনুপস্থিত রয়েছে এমন জায়গাগুলি সনাক্ত করতে এই প্রশ্নের জন্য ক্যোয়ারী পরিকল্পনাটি দেখার জন্য বিকল্পটি ব্যবহার করুন ।
আরও তথ্যের জন্য http://dev.mysql.com/doc/refman/5.0/en/slow-query-log.html দেখুন ।