আমার একটি মাইএসকিউএল টেবিল রয়েছে যেখানে সারিগুলি গতিশীলভাবে areোকানো হয়। যেহেতু আমি স্ট্রিংয়ের দৈর্ঘ্যের বিষয়ে নিশ্চিত হতে পারি না এবং সেগুলি কেটে ফেলতে চাই না, তাই আমি তাদের ভার্চার (200) তৈরি করি যা সাধারণত আমার প্রয়োজনের চেয়ে অনেক বড়। কোনও ভার্চার ক্ষেত্র প্রয়োজনের তুলনায় আরও বেশি দৈর্ঘ্য দেওয়ার ক্ষেত্রে কি কোনও বড় পারফরম্যান্স হিট আছে?
উত্তর:
না, এই অর্থে যে that কলামটিতে আপনি যে মানগুলি সংরক্ষণ করছেন তা যদি সর্বদা (বলুন) কমপক্ষে 50 টি অক্ষরের চেয়ে কম কলাম ঘোষিত হয় varchar(50)বা varchar(200)একই কর্মক্ষমতা থাকে।
সম্ভাব্য পারফরম্যান্সের একটি প্রভাব রয়েছে: মাইএসকিউএলে, অস্থায়ী সারণী এবং MEMORYটেবিলগুলি VARCHARএকটি নির্দিষ্ট দৈর্ঘ্যের কলাম হিসাবে একটি কলামকে সর্বাধিক দৈর্ঘ্যে প্যাড করে রাখে। আপনি যদি VARCHARপ্রয়োজন সর্বাধিক আকারের তুলনায় কলামগুলি আরও বড় করে ডিজাইন করেন তবে আপনার নিজের তুলনায় আরও বেশি মেমোরি ব্যবহার করবেন। এটি ক্যাশে দক্ষতা, বাছাইয়ের গতি ইত্যাদিকে প্রভাবিত করে
MEMORYটেবিলটি খুব বড় হিসাবে বিবেচিত হয়, তখন এটি ডিস্কে লিখিত হয়, যার ফলে কার্য সম্পাদনের তাৎপর্য হ্রাস পায়।
সীমা, আপনার উদাহরণ উপর ভিত্তি করে, 200 টি অক্ষর হবে কিন্তু কিছু কম গ্রহণ করা হয় - কারণ এটি "পরিবর্তনশীল চরিত্র" ঘোরা VARCHAR, পরিস্থিতি আপনি বর্ণনা জন্য আদর্শ এবং কলামের বরাদ্দ আকার পূরণ হবে না।
VARCHAR এছাড়াও কম স্থান নেয় - মানগুলি একটি বাইট বা দুই-বাইট দৈর্ঘ্যের উপসর্গ প্লাস ডেটা হিসাবে সংরক্ষণ করা হয়। দৈর্ঘ্যের উপসর্গটি মানটিতে বাইটের সংখ্যা নির্দেশ করে। মানগুলিতে 255 বাইটের বেশি প্রয়োজন না হলে একটি কলামে একটি দৈর্ঘ্য বাইট ব্যবহার করা হয়, মানগুলিতে 255 বাইটের বেশি প্রয়োজন হতে পারে যদি দুটি দৈর্ঘ্য বাইট।
মাইএসকিউএল সিএএইচআর CHAR এর সাথে VARCHAR ডেটাটাইপগুলি তুলনা করে আরও তথ্যের জন্য, এই লিঙ্কটি দেখুন ।
আকারের পারফরম্যান্স! আকার যত ছোট হবে তত ভাল। আজ বা কাল নয়, কোনও দিন আপনার টেবিলগুলি আকারে বড় হবে যখন এটি গুরুতর বাধা নিয়ে আসে, আপনি কোনও নকশাই রেখেছিলেন তা বিবেচনা করেই নয়। তবে আপনি আপনার ডিজাইনের পর্যায়ে এমন কয়েকটি সম্ভাব্য বাধা সম্পর্কে ধারণা করতে পারেন যা সম্ভবত ঘটতে পারে এবং আপনার ডিবি দ্রুত এবং সুখীভাবে সঞ্চালনের সময়টি প্রসারিত করার চেষ্টা করবেন যতক্ষণ না আপনি আরও বেশি সার্ভার যুক্ত করে আপনার স্কিম বা অনুভূমিকভাবে স্কেলটি পুনর্বিবেচনার প্রয়োজন হয়।
আপনার ক্ষেত্রে এমন অনেকগুলি পারফরম্যান্স ফাঁস রয়েছে যা আপনি চালাতে পারেন: বড় varcharকলামগুলি দীর্ঘ কলামগুলির সাথে প্রায় অসম্ভব । এই কলামগুলিতে সূচীকরণ একটি আসল হত্যাকারী। আপনার ডিস্কে ডেটা সংরক্ষণ করতে হবে। একটি স্মৃতি পৃষ্ঠা কম সারি ধরে রাখতে পারে এবং টেবিল স্ক্যানগুলি অনেক ধীর হবে। এছাড়াও ক্যোয়ারী ক্যাশে আপনাকে এখানে সহায়তা করার সম্ভাবনা কম।
নিজেকে জিজ্ঞাসা করতে হবে: প্রতি বছর কতগুলি সংঘটিত হতে পারে? গড় দৈর্ঘ্য কত? আমার কি সত্যিই 200 টিরও বেশি অক্ষরের প্রয়োজন বা আমি আমার অ্যাপ্লিকেশনের সম্মুখ-প্রান্তে এমনকি ব্যবহারকারীদের সর্বোচ্চ দৈর্ঘ্য সম্পর্কে অবহিত করে তা ধরতে পারি? আমি কি দ্রুত তালিকাবদ্ধকরণ এবং স্ক্যানিংয়ের জন্য টেবিলটিকে একটি সংকীর্ণ এবং অন্যটি বাড়ানোর আকারের অতিরিক্ত, কম ঘন ঘন প্রয়োজনীয় ডেটা রাখার জন্য অন্য একটিতে বিভক্ত করতে পারি? আমি কি সম্ভাব্য ভার্চার ডেটা বিভাগগুলিতে টাইপ করতে পারি এবং তাই কিছুটা ছোট, সম্ভবত ইনট বা বুল-টাইপ কলামগুলিতে কিছু ডেটা বের করতে পারি এবং সেইভাবে ভারচার কলামটি সংকীর্ণ করতে পারি?
আপনি এখানে অনেক কিছু করতে পারেন। সত্যিকারের জীবন পরিমাপকৃত পারফরম্যান্স ডেটা ব্যবহার করে প্রথম অনুমানের সাথে যেতে এবং তারপরে ধাপে ধাপে পুনরায় নকশা করা ভাল। শুভকামনা।
কর্মক্ষমতা? নং ডিস্ক স্টোরেজ? হ্যাঁ, তবে এটি সস্তা এবং প্রচুর। যদি না আপনার ডাটাবেস টেরাবাইট স্কেলে বৃদ্ধি পায় তবে আপনি সম্ভবত ঠিক আছেন।
আপনারা কেউ কেউ ভেবে ভুল করছেন যে varchar(200)এটির চেয়ে ডিস্কে আরও টেবিলের আকার থাকে varchar(20)। এই ক্ষেত্রে না হয়. আপনি যখন 255 অক্ষরের বাইরে চলে যান কেবল তখনই mysql varcharক্ষেত্রের ডেটার দৈর্ঘ্য নির্ধারণ করতে অতিরিক্ত বাইট ব্যবহার করে।
MEMORYটেবিলের জন্য তাই নয় ।
পারফরম্যান্স হিট হতে পারে - তবে সাধারণত এমন স্তরে নয় যা বেশিরভাগ ব্যবহারকারীরা লক্ষ্য করবেন।
যখন প্রতিটি ক্ষেত্রের আকার অগ্রিম জানা যায়, তখন মাইএসকিউএল প্রতিটি ক্ষেত্র / সারির মধ্যে কতগুলি বাইট থাকে তা ঠিক জানে এবং সমস্ত ডেটা না পড়েই পৃষ্ঠাতে এগিয়ে যেতে পারে। পরিবর্তনশীল অক্ষর ব্যবহার অপ্টিমাইজেশনের জন্য এই ক্ষমতা হ্রাস করে।
ডেটা বিভাজনের কারণে ভারচার কি ফলাফল সম্পাদন করে?
আরও ভাল, চর বনাম বার্চর ।
সবচেয়ে ব্যবহারের জন্য, হয় আপনি সাথে জরিমানা হবে - কিন্তু হয় একটি পার্থক্য, এবং বড় স্কেল ডাটাবেস জন্য, কারণ আপনি এক বা অন্যান্য বাছাই চাই হয়।
বর্ণচালক হওয়ার পরিবর্তে, আকারটি তার প্রকৃত দৈর্ঘ্য এবং স্ট্রিংটি নিজেই নির্দেশ করতে অভ্যন্তরীণ ক্ষেত্রের উপর ভিত্তি করে। সুতরাং ভার্চর (200) ব্যবহার করা ভার্চর (150) ব্যবহার করা খুব আলাদা নয়, আপনার আরও সঞ্চয় করার সম্ভাবনা রয়েছে।
এবং একটি আপডেটে কী ঘটে, যখন একটি সারি বড় হয় তখন আপনার বিবেচনা করা উচিত। তবে এটি যদি বিরল হয় তবে আপনার ভাল হওয়া উচিত।
ডেটাটাইপ নাম অনুসারে এটি VARCHAR, যেমন ভেরিয়েবল অক্ষর ডেটা স্টোরেজ, মাইএসকিএল ইঞ্জিন নিজেই মেমরির সঞ্চিত তথ্য হিসাবে ব্যবহৃত মেমরির বরাদ্দ করে, তাই আমার জ্ঞান অনুযায়ী কোনও পারফরম্যান্স হিট হয় না।
বেশিরভাগ পরিস্থিতিতে আপনার চর কলামের মতো ভার্চর কলামটি দেখার চেষ্টা করা উচিত এবং দৈর্ঘ্যটি রক্ষণশীলভাবে সেট করা উচিত। আপনাকে সর্বদা ভেরিফাইফায়ার সম্পর্কে এতদূর ভাবতে হবে না যে এমন কিছু যা আপনার দৈর্ঘ্যের উপর নির্ভর করে আপনার সিদ্ধান্তকে প্রভাবিত করে। এটিকে সত্যিকার অর্থে পারফরম্যান্সের ইঙ্গিত হিসাবে দেখা উচিত যে সরবরাহ করা স্ট্রিংগুলি বিভিন্ন দৈর্ঘ্যের হবে।
এটি কোনও নির্দেশ নয় যা ডাটাবেস ইন্টার্নালদের কঠোরভাবে অনুসরণ করতে হবে, এটি সম্পূর্ণ উপেক্ষা করা যায়। যদিও এর সাথে কখনও কখনও বাস্তবায়ন ফাঁস হতে পারে (যেমন নির্দিষ্ট দৈর্ঘ্য এবং প্যাডিং উদাহরণস্বরূপ) যদিও এটি কোনও আদর্শ বিশ্বে না হওয়া উচিত care
আপনার যদি একটি ভার্চার (255) থাকে তবে আপনার কোনও গ্যারান্টি নেই যে পারফরম্যান্স অনুযায়ী এটি সর্বদা সমস্ত ক্ষেত্রে একটি চর (255) এর সাথে আলাদাভাবে আচরণ করবে।
স্টোরেজের প্রয়োজনীয়তা সম্পর্কে ম্যানুয়ালটিতে দেওয়া পরামর্শের সাথে এটি ইনলাইন হিসাবে 255, 65535 ইত্যাদির মতো সেট করা সহজ বলে মনে হচ্ছে। এটি এই ধারণাটি দেয় যে 0 (হ্যাঁ, এটি একটি জিনিস) এবং 255 এর মধ্যে যে কোনও মান একই প্রভাব ফেলবে। তবে এটি এমন কিছু নয় যা পুরোপুরি গ্যারান্টিযুক্ত হতে পারে।
স্টোরের প্রয়োজনীয়তাগুলি সত্য হতে বা সারি স্টোরেজের ক্ষেত্রে শালীন এবং পরিপক্ক ধ্রুবক স্টোরেজ ইঞ্জিনগুলির জন্য একটি ভাল সূচক থাকে। এটি সূচকের মতো জিনিসের পক্ষে শক্তিশালী সূচক নয়।
এটি কখনও কখনও একটি কঠিন প্রশ্ন, ঠিক কতক্ষণ স্ট্রিংয়ের টুকরোটি এটি সর্বোচ্চ বেঁধে স্থাপন করা উচিত আপনি জানেন যে এটির মধ্যে থাকা উচিত তবে এর কোনও প্রভাব নেই। দুর্ভাগ্যক্রমে এটি প্রায়শই ব্যবহারকারীর কাজ করার জন্য ছেড়ে যায় এবং এটি কিছুটা নির্বিচারে। আপনি সত্যই কখনই স্ট্রিংকে বড় করতে পারবেন না কারণ এমন ঘটনাও ঘটতে পারে যেখানে আপনি ঠিক নিশ্চিত নন।
আপনার নিশ্চিত করা উচিত যে মাইএসকিউএল অনুসন্ধানগুলি যখন একটি স্ট্রিংটি কাটা কাটার চেয়ে খুব দীর্ঘ হয় তখন ত্রুটি ছুঁড়ে দেয় যাতে কমপক্ষে আপনি জানেন যে এটি ত্রুটি নির্গমন থেকে খুব কম হতে পারে। কলামগুলি বড় বা সঙ্কুচিত করতে পুনরায় আকার দেওয়া একটি ব্যয়বহুল ডিডিএল অপারেশন হতে পারে, এটি মনে রাখা উচিত।
দৈর্ঘ্য এবং পারফরম্যান্স খেলতে আসে যেখানে অক্ষর সেটটিও বিবেচনা করা উচিত। দৈর্ঘ্য বাইটের চেয়ে এটি বোঝায়। উদাহরণস্বরূপ, utf8 ব্যবহার করে যদি (এমবি 4 নয়) তবে বর্ণচর (255) সত্যিই ভের্বাইনারি (3 * 255)। পরীক্ষাগুলি না চালিয়ে এবং সোর্স কোড / ডকুমেন্টেশনের গভীরভাবে অনুসন্ধান না করে কীভাবে এই জাতীয় জিনিসগুলি সত্যই কার্যকর হবে তা জানা শক্ত। এ কারণে অপ্রত্যাশিতভাবে স্ফীত প্রভাব পড়ার অতিরিক্ত দৈর্ঘ্যের সুযোগ রয়েছে। এটি কেবল পারফরম্যান্সে প্রযোজ্য নয়। যদি আপনার একদিন ভার্চর কলামের চরিত্রের সেটটি আরও বড় আকারে পরিবর্তন করতে হয় তবে আপনি যদি কৃত্রিমভাবে দীর্ঘ স্ট্রিংগুলি উপস্থিত থাকতে দিতেন তবে এড়ানো যেত। এটি সাধারণত একটি মোটামুটি কুলুঙ্গির সমস্যা তবে এটি উঠে আসে,
যদি দেখা যায় যে MAX (LENGTH (কলাম)) সর্বদা <64 থাকে (যেমন যদি সিদ্ধান্ত নেওয়া হয়েছিল যে ইনপুটটির কোনও সীমা থাকবে যা কলাম সংজ্ঞা অনুসারে মেলেনি) তবে আপনার ভারচার (255) আছে তবে আপনি কিছু পরিস্থিতিতে প্রয়োজনের চেয়ে চারগুণ বেশি জায়গা ব্যবহার করবেন এমন ভাল সুযোগ।
এর মধ্যে অন্তর্ভুক্ত থাকতে পারে:
থাম্বের একটি নিয়ম হিসাবে, কোনও বার্চারের যেভাবেই হওয়া দরকার তার চেয়ে বেশি দীর্ঘায়নের প্রয়োজন নেই, পারফরম্যান্সের সমস্যাগুলি বা না তাই আমি যখন আপনি এটি করতে পারেন তার সাথে লেগে থাকার পরামর্শ দিই। আপনার ডেটার আকারের নমুনার জন্য আরও প্রচেষ্টা করা, একটি সত্য সীমা প্রয়োগ করা বা জিজ্ঞাসা / গবেষণার মাধ্যমে সত্য সীমাটি সন্ধান করা আদর্শ পদ্ধতির।
আপনি যখন পারবেন না, যদি সন্দেহের ক্ষেত্রে আপনি যদি ভারচার (255) এর মতো কিছু করতে চান তবে আমি বিজ্ঞানটি করার পরামর্শ দিই। এটিতে টেবিলটিকে নকল করে, ভ্যার চর কলামের আকার হ্রাস করে তারপরে ডাটাটি মূল থেকে অনুলিপি করে এবং সূচি / সারির তথ্যের আকারের দিকে তাকিয়ে থাকতে পারে (পাশাপাশি কলামটিও সূচী করে এটি প্রাথমিক কী হিসাবে চেষ্টা করুন) প্রাথমিক কী দ্বারা সারিগুলি অর্ডার করা হওয়ায় InnoDB এ অন্যরকম আচরণ করতে পারে)। খুব কমপক্ষে এই পথে আপনি জানতে পারবেন আপনার আইও-তে কোনও প্রভাব রয়েছে যা সবচেয়ে সংবেদনশীল বাধা হয়ে থাকে। মেমরির ব্যবহারের জন্য পরীক্ষা করা আরও কঠিন, সম্পূর্ণরূপে এটি পরীক্ষা করা শক্ত। আমি সম্ভাব্য সবচেয়ে খারাপ ক্ষেত্রে (মেমরির ফলাফলগুলিতে মধ্যবর্তী প্রচুর পরিমাণের প্রশ্নগুলি, বড় টেম্প টেবিলগুলির জন্য ব্যাখ্যা সহ চেক ইত্যাদি) পরীক্ষা করার পরামর্শ দেব।
আপনি যদি জানেন যে টেবিলটিতে অনেকগুলি সারি থাকবে না, আপনি যোগদান করে, সূচীগুলি (বিশেষত সংমিশ্রিত, অনন্য), ইত্যাদির জন্য কলামটি ব্যবহার করবেন না তবে সম্ভবত আপনার খুব সমস্যা হবে না।
VARCHAR(255) utf8mb411.5MB পরিমাপকৃত একক ইনডেক্স কলাম সহ 150 ডলার সারি সহ একটি টেবিল ।VARCHAR(48) utf8mb4একই ডেটা (সর্বাধিক দৈর্ঘ্যের 46 অক্ষর) সহ সূচিযুক্ত কলামযুক্ত একটি টেবিল 4.5MB ব্যবহৃত হয়েছে। প্রশ্নগুলির মধ্যে আসলে কোনও বড় পার্থক্য নয়, এটি সূচকযুক্ত। তবে এটি ক্যোয়ারী I / O এবং ডেটাবেস ব্যাকআপের মতো জিনিস যুক্ত করে।