আমি একটি টেবিল তৈরির প্রক্রিয়াধীন এবং এটি আমাকে অবাক করে দিয়েছিল।
যদি আমি সঞ্চয় করি, গাড়িগুলি বলুন যেগুলির একটি মেক আছে (fx BMW, অডি ect।), যদি আমি মেক বা ইনচার্চার হিসাবে মেকটি সঞ্চয় করি তবে কী ক্যোয়ারী গতিতে কোনও পার্থক্য হবে?
তাই হয়
SELECT * FROM table WHERE make = 5 AND ...;এর চেয়ে দ্রুত / ধীর
SELECT * FROM table WHERE make = 'audi' AND ...;বা গতি কমবেশি একই হবে?
উত্তর:
ইন্টার তুলনাগুলি ভারচরের তুলনার তুলনায় দ্রুততর, সাধারণ বিষয়গুলির জন্য যে ইনচারগুলি ভারচারগুলির তুলনায় অনেক কম স্থান নেয়।
আনইনডেক্স এবং ইনডেক্সেড অ্যাক্সেসের জন্য এটি উভয়ই সত্য। যাওয়ার দ্রুততম উপায় হ'ল একটি সূচকযুক্ত ইন কলাম।
আমি দেখতে পাচ্ছি যে আপনি পোস্টগ্রিক প্রশ্নটি ট্যাগ করেছেন, আপনি বিভিন্ন তারিখের স্থানের স্থান ব্যবহারে আগ্রহী হতে পারেন:
intক্ষেত্রগুলি 2 থেকে 8 বাইটের মধ্যে দখল করে , সাধারণত 4 টি পর্যাপ্ত পরিমাণে বেশি থাকে (-2147483648 থেকে +2147483647)কিছু রুক্ষ মানদণ্ড:
Postgres 9.x এ 4 মিলিয়ন রেকর্ড
Table A = base table with some columns
Table B = Table A + extra column id of type bigint with random numbers
Table C = Table A + extra column id of type text with random 16-char ASCII strings8 জিবি র্যাম, আই 7, এসএসডি ল্যাপটপের ফলাফল:
Size on disk: A=261MB B=292MB C=322MB
Non-indexed by id: select count(*), select by id: 450ms same on all tables
Insert* one row per TX: B=9ms/record C=9ms/record
Bulk insert* in single TX: B=140usec/record C=180usec/record
Indexed by id, select by id: B=about 200us C=about 200us
* inserts to the table already containing 4M recordsসুতরাং এই সেটআপটির জন্য দেখে মনে হচ্ছে, যতক্ষণ আপনার সূচীগুলি রামে ফিট থাকে ততক্ষণ বিগিন্ট বনাম 16-চরের পাঠের গতিতে কোনও পার্থক্য নেই।
এটি একটি ভার্চারের পরিবর্তে কোনও int ব্যবহার করে কিছুটা দ্রুত হবে। গতির জন্য আরও গুরুত্বপূর্ণ ক্ষেত্রটিতে এমন একটি সূচক রয়েছে যা কোয়েরিটি রেকর্ডগুলি সন্ধান করতে ব্যবহার করতে পারে।
ইন্ট ব্যবহার করার অন্য একটি কারণ রয়েছে এবং তা হ'ল ডাটাবেসকে স্বাভাবিক করা। 'মার্সিডিজ-বেঞ্জ' পাঠ্যটি টেবিলে হাজারবার সঞ্চারিত না করে আপনার আইডিটি সংরক্ষণ করা উচিত এবং ব্র্যান্ডের নামটি আলাদা টেবিলে একবার সঞ্চয় করা উচিত।
Mercedes-Benzহাজার হাজার বার আইডি সংরক্ষণ করার পরিবর্তে আপনার অর্থ কী 1? উদাহরণস্বরূপ সারণী car_brands, কলাম Brandsএবং Id। সারি Mercedes-Benzএবং 1। এবং প্রধান টেবিল কলাম Brandsএবং মান 1। এবং কখন SELECT, তারপরে প্রথমে Idটেবিল থেকে car_brandsএবং তারপরে SELECT Something FROM main_table WHERE Brands = (SELECT Id FROM car_brands WHERE Brands = Mercedes-Benz)। নাকি অন্য কোন পন্থা?
select something from main_table c inner join car_brands b on b.Id = c.Brands where b.Brands = 'Mercedes-Benz'।
স্ট্রিং তুলনা বনাম অ-ফ্লোটগুলির প্রকৃত কার্য সম্পাদনকে সরিয়ে ফেলা, এক্ষেত্রে স্বাক্ষরবিহীন ও স্বাক্ষরযুক্ত কোনও আকারের বিষয়টি বিবেচনা করে না। আকার আসলে পারফরম্যান্সের মধ্যে সত্য পার্থক্য। এটি 1byte + (126bytes পর্যন্ত) বনাম 1,2,4 বা 8 বাইট তুলনা ... স্পষ্টতই নন-ফ্লোট স্ট্রিং এবং ফ্লোটের চেয়ে ছোট এবং এইভাবে সমাবেশে আরও সিপিইউ বান্ধব।
সমস্ত ভাষায় স্ট্রিং তুলনা স্ট্রিং সিপিইউ দ্বারা 1 নির্দেশনা তুলনা করা যেতে পারে যে কিছু চেয়ে ধীর। এমনকি একটি 32 বিট সিপিইউতে 8 বাইট (64 বিট) তুলনা করা এখনও ভিআচআরএআরএর (2) বা তার চেয়ে বড় এর চেয়ে দ্রুত। * আবার, উত্পাদিত সমাবেশটি দেখুন (এমনকি হাতেও) এটি 1 থেকে 8 বাইট সিপিইউ সংখ্যার চেয়ে চরের সাথে তুলনামূলক আরও বেশি নির্দেশনা দেয়।
এখন, কত দ্রুত? তথ্যের পরিমাণের উপরও নির্ভর করে। যদি আপনি কেবল 5 থেকে 'অডি' তুলনা করে থাকেন - এবং এটি আপনার ডিবিতে রয়েছে তবে ফলস্বরূপ পার্থক্যটি এত ন্যূনতম যে আপনি এটি কখনই দেখতে পাবেন না। সিপিইউ, বাস্তবায়ন (ক্লায়েন্ট / সার্ভার, ওয়েব / স্ক্রিপ্ট ইত্যাদি) এর উপর নির্ভর করে আপনি সম্ভবত এটি দেখতে পাবেন না যতক্ষণ না আপনি ডিবি সার্ভারে কয়েকশ তুলনা হিট করেন (এটি লক্ষণীয় হওয়ার আগে কয়েক হাজার তুলনাও হতে পারে)।
Ozz
সূচক বা না, ইনট অনেক দ্রুত (ভার্চার যত দীর্ঘতর হয়, ধীরে ধীরে এটি পায়)।
আর একটি কারণ: বার্চার ফিল্ডে সূচকটি ইনট-এর চেয়ে অনেক বড় হবে। বৃহত্তর টেবিলগুলির জন্য এটি কয়েকশ মেগাবাইট (এবং হাজার হাজার পৃষ্ঠা) এর অর্থ হতে পারে। এটি কার্য সম্পাদনকে আরও খারাপ করে তোলে কারণ একা সূচকটি পড়তে অনেকগুলি ডিস্কের পড়া প্রয়োজন।
ইঙ্গিত: ক্ষেত্রের জন্য সম্ভাব্য মান যদি করতে হবে না (অথবা কদাচিৎ) পরিবর্তন করুন, আপনি ENUM সমঝোতার যেমন ব্যবহার করতে পারেন। এটি ভাল পঠনযোগ্যতার সাথে ভাল গতির একত্রিত করে।
enumডেটা টাইপ আছে? আমি যদিও এটি মাইএসকিউএল নির্দিষ্ট ছিল।
কিছুটা আপেক্ষিক। হ্যাঁ, আইএনটি দ্রুততর হবে, তবে এটি যদি আপনার পরিস্থিতিতে লক্ষ্যণীয় হয় তবে প্রশ্ন is ভর্চারগুলি কি কেবল কিছু ছোট শব্দ, বা দীর্ঘতর পাঠ্য? এবং টেবিলের মধ্যে কত সারি রয়েছে? যদি কেবল কয়েকটি সারি থাকে তবে এটি সম্ভবত মেমরির সম্পূর্ণভাবে বাফার হবে (যখন প্রায়ই অনুরোধ করা হয়) তবে আপনি খুব বেশি পার্থক্য লক্ষ্য করতে পারবেন না। তারপরে অবশ্যই ইনডেক্সিং রয়েছে, যা টেবিল বাড়ার সাথে আরও গুরুত্বপূর্ণ হয়ে ওঠে। এসএসডি ব্যবহার করা দ্রুততর হতে পারে তারপরে অপ্টিমাইজড কোয়েরিগুলির সাথে এইচডি। এছাড়াও ভাল ডিস্ক-নিয়ন্ত্রকরা মাঝে মাঝে প্রশ্নের> 10x গতি বাড়ায়। এটি কেবলমাত্র VARCHARs ব্যবহারের জন্য জায়গা ছেড়ে দিতে পারে যা পাঠ এবং লেখাগুলি প্রশ্নের সহজ করে তোলে (জটিল যোগদানের প্রয়োজন নেই) এবং বিকাশের গতি বাড়ায়। পুরিস্টরা তবে দ্বিমত এবং সর্বদা সবকিছু স্বাভাবিক করবে normal