নির্বাচন করুন * বনাম নির্বাচন করুন কলাম

124

যদি আমার কেবল ২/৩ টি কলাম প্রয়োজন হয় এবং আমি SELECT *নির্বাচিত কোয়েরিতে এই কলামগুলি সরবরাহ করার পরিবর্তে জিজ্ঞাসা করি, আরও / কম আই / ও বা মেমরি সম্পর্কিত কোনও কর্মক্ষমতা হ্রাস পাচ্ছে কি?

আমি প্রয়োজন ছাড়া * সিলেক্ট করলে নেটওয়ার্ক ওভারহেড উপস্থিত থাকতে পারে।

তবে একটি নির্বাচন অপারেশনে, ডাটাবেস ইঞ্জিনটি কি সর্বদা ডিস্ক থেকে পারমাণবিক টুপল টানতে পারে, বা এটি কেবল নির্বাচিত অপারেশনে অনুরোধ করা those কলামগুলি টানতে পারে?

যদি এটি সর্বদা একটি টুপল টান দেয় তবে আমি / ও ওভারহেড একই।

একই সময়ে, টিপল থেকে অনুরোধ করা কলামগুলি সরিয়ে ফেলার জন্য মেমরির খরচ হতে পারে, যদি এটি একটি টুপল টান দেয়।

সুতরাং যদি এটি হয় তবে সিলেক্ট কলামের সিলেক্টের চেয়ে বেশি মেমরির ওভারহেড থাকবে

sql performance

— নীল বসু
সূত্র

আপনি জিজ্ঞাসা করছেন একটি নির্দিষ্ট আরডিবিএমএস আছে? এটি সম্ভব যে কীভাবে SELECTপ্রশ্নগুলি কার্যকর করা হয় / প্রক্রিয়া করা হয় তা ডেটাবেস থেকে ডাটাবেসের চেয়ে আলাদা।

— রাষ্ট্রদ্রোহিতা majesté

10

একদিকে যেমন পোস্টগ্র্যাসকিউএল-তে আপনি যদি বলেন CREATE VIEW foo_view AS SELECT * FROM foo;, তবে পরে টেবিল ফু-তে কলামগুলি যুক্ত করুন, সেই কলামগুলি স্বয়ংক্রিয়ভাবে foo_ View- তে প্রত্যাশা অনুযায়ী প্রদর্শিত হবে না। অন্য কথায়, *এই প্রসঙ্গটি কেবল একবারে প্রসারিত হয় (দেখার সময় নির্মাণের সময়), প্রতি নির্বাচন হিসাবে নয়। ALTER TABLE থেকে উদ্ভূত জটিলতার কারণে, আমি বলব যে ( *বাস্তবে ) ক্ষতিকারক হিসাবে বিবেচিত।

— জোয়ে অ্যাডামস

@ জোয়্যা অ্যাডামস - কেবল পোস্টগ্র্যাসকিউএল নয়, এটি ওরাকেলের আচরণও।

— এপিসি

1

@ ওএমজি পনিস: আমি এই জাতীয় পোস্ট সম্পর্কে সচেতন ছিলাম না। তবে এগুলি সত্যই সিমেলার নয় iler @ লুস ম্যাজেস্টé: আমি জেনেরিক আরডিবিএমএসের কথা বলছি। কোনও নির্দিষ্ট বিক্রেতা @ জোয়ি অ্যাডামস সম্পর্কে নয়: হুম আমি জানি যে * অনিরাপদ। শুধু সম্পর্কিত পারফরম্যান্স বিষয় নিয়ে আলোচনা করতে চান।

— নীল বসু

3

সম্ভাব্য নকল কেন নির্বাচন * ক্ষতিকারক হিসাবে বিবেচিত?

— অ্যারন বারট্র্যান্ড

31

এটি সর্বদা একটি টুপল টান করে (কেবলমাত্র টেবিলটি উল্লম্বভাবে ভাগ করা হয়েছে - কলামগুলির টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো টুকরো হয়ে) যাইহোক, অন্যান্য অনেক কারণে, (নীচে) আপনার সর্বদা নাম হিসাবে বিশেষভাবে সেই কলামগুলি নির্বাচন করা উচিত।

এটি সর্বদা একটি টুপল টান দেয়, কারণ (প্রতিটি বিক্রেতাদের মধ্যে আমি পরিচিত, আরডিবিএমএস), প্রতিটি কিছুর জন্য অন্তর্নিহিত অন-ডিস্ক স্টোরেজ কাঠামো (টেবিল ডেটা সহ) সংজ্ঞায়িত I / O পৃষ্ঠাগুলির উপর ভিত্তি করে (যেমন এসকিউএল সার্ভারে উদাহরণস্বরূপ, প্রতিটি পৃষ্ঠা 8 কিলোবাইট)। এবং প্রতিটি I / O পড়া বা লেখা পৃষ্ঠা দ্বারা হয় .. অর্থাত, প্রতিটি লেখা বা পঠন একটি সম্পূর্ণ পৃষ্ঠার ডেটা।

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

ব্যতিক্রম। একমাত্র জায়গা যেখানে Select *ঠিক আছে, কোনও Existsবা Not Existsভবিষ্যদ্বাণীক অনুচ্ছেদের পরে সাব- কোয়েরিতে রয়েছে যেমন রয়েছে:

   Select colA, colB
   From table1 t1
   Where Exists (Select * From Table2
                 Where column = t1.colA)

সম্পাদনা: @ মাইক শেরার মন্তব্যে সম্বোধন করার জন্য, হ্যাঁ প্রযুক্তিগতভাবে, আপনার বিশেষ ক্ষেত্রে এবং নান্দনিকভাবে কিছুটা সংজ্ঞা সহ এটি সত্য। প্রথমত, যখন অনুরোধকৃত কলামগুলির সেটটি কিছু সূচীতে সঞ্চিত সেগুলির একটি উপসেট হয়, তবুও ক্যোয়ারী প্রসেসরের অবশ্যই সেই সূচীতে সঞ্চিত প্রতিটি কলামই আনতে হবে , কেবল অনুরোধ করা নয়, একই কারণে - সমস্ত আই / ও অবশ্যই করতে হবে পৃষ্ঠাগুলি এবং সূচী ডেটা আইও পৃষ্ঠাগুলিতে সারণী ডেটার মতো সংরক্ষণ করা হয়। সুতরাং আপনি যদি সূচীতে সঞ্চিত কলামগুলির সেট হিসাবে কোনও সূচী পৃষ্ঠার জন্য "টুপল" সংজ্ঞায়িত করেন তবে বিবৃতিটি এখনও সত্য।
এবং বিবৃতিটি নান্দনিকভাবে সত্য কারণ বিন্দুটি হ'ল এটি I / O পৃষ্ঠায় সঞ্চিত কী আছে তার উপর ভিত্তি করে ডেটা সংগ্রহ করে, আপনি যা চেয়েছিলেন তার ভিত্তিতে নয় এবং আপনি বেস টেবিল I / O পৃষ্ঠা বা সূচি অ্যাক্সেস করছেন কিনা তা সত্য আই / ও পৃষ্ঠা

অন্যান্য কারণে ব্যবহার না করার জন্য Select *দেখুন কেন SELECT *ক্ষতিকারক হিসাবে বিবেচিত হয়? :

— চার্লস ব্রেটানা
সূত্র

"এটি সর্বদা একটি টুপল টান" আপনি কি নিশ্চিত? হুম ঠিক আছে আমি ঠিক বলেছি। যদি এটি হয় তবে ক্ষেত্রে আই / ও ওভারহেডের select *চেয়ে কম মেমরির ওভারহেড থাকবে select column। সুতরাং যদি আমরা নেটওয়ার্ক ওভারহেড ছেড়ে। select *এর চেয়ে কম যদি ওভারহেড হয়select column

— নীল বসু

10

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

— মাইক শেরভ

হ্যাঁ যদি অনুরোধ করা টিপলের সেটটি স্মৃতিতে থাকে তবে সেখানে কোনও আই / ও থাকবে না তবে এটি বিশেষ ক্ষেত্রে চলে। সুতরাং সংক্ষেপে কি। আমি যদি কিছু সূচিকৃত কলাম নির্বাচন করি তবে পুরো টিপলটি পড়ে না? নাহলে পুরো টিপল পড়ে যায়?

— নীল বসু

আমি মাইএসকিএল কীভাবে ক্যাশে করে তা নিশ্চিত নই, তবে এসকিউএল সার্ভারে এবং ওরাকল-এ, এমনকি যখন ডেটা ইন-মেমোরি ক্যাশে থাকে তখনও এটি ডিস্ক থেকে অ্যাক্সেস করার সময় একই পৃষ্ঠা কাঠামোটি ব্যবহার করে এটি অ্যাক্সেস করে। অর্থাত এর জন্য ডেটা প্রতি পৃষ্ঠায় একটি মেমরি I / O প্রয়োজন হবে ... এটি ডিস্ক থেকে ঠিক একই রকম হবে। (স্মৃতি ব্যতীত I / Os অবশ্যই ডিস্ক I / Os এর চেয়ে অনেক দ্রুত)। প্রকৃতপক্ষে, ডেটা অবস্থানের অ্যাক্সেস প্রক্রিয়া সম্পূর্ণ স্বতন্ত্র করতে, এটি ক্যাশেড ডিজাইনের লক্ষ্য of

— চার্লস ব্রেটানা

2

আপনি কি "অন্যান্য অনেক কারণে" আরও বেশি করে বানান করতে পারেন? কারণ এগুলি আমার কাছে পরিষ্কার ছিল না। যদি পারফরম্যান্সটি গুরুত্বপূর্ণ না হয় তবে কলামের নামগুলি অনুরোধ করার বিষয়ে যত্ন কেন করছেন?

— ডেনিস

111

SELECT *উত্পাদনের কোডে আপনার কখনই (কখনও কখনও) ব্যবহার করা উচিত নয় এমন কয়েকটি কারণ রয়েছে :

যেহেতু আপনি আপনার ডাটাবেসটিতে যা চান তার কোনও ইঙ্গিত দিচ্ছেন না, সেই টেবিলের কলামগুলি নির্ধারণ করার জন্য প্রথমে টেবিলের সংজ্ঞাটি পরীক্ষা করা দরকার। এই অনুসন্ধানের জন্য কিছু সময় ব্যয় হবে - একক ক্যোয়ারিতে খুব বেশি নয় - তবে এটি সময়ের সাথে যুক্ত হয়
আপনার যদি মাত্র 2/3 কলামের প্রয়োজন হয়, আপনি 1/3 খুব বেশি ডেটা নির্বাচন করছেন যা ডিস্ক থেকে পুনরুদ্ধার করা দরকার এবং নেটওয়ার্ক জুড়ে প্রেরণ করা দরকার
আপনি যদি ডেটার কয়েকটি নির্দিষ্ট বিষয়ের উপর নির্ভর করতে শুরু করেন, যেমন কলামগুলির ক্রম ফিরে এসেছে, টেবিলটি পুনর্গঠিত হয়ে গেলে এবং নতুন কলামগুলি যুক্ত হয়ে গেলে (বা বিদ্যমানগুলি সরিয়ে দেওয়া হয়েছে) আপনি একটি বাজে চমক পেতে পারেন
এসকিউএল সার্ভারে (অন্যান্য ডাটাবেসের বিষয়ে নিশ্চিত নয়), যদি আপনার কলামগুলির একটি উপসেট প্রয়োজন হয়, সর্বদা একটি নন-ক্লাস্টারড সূচক সেই অনুরোধটি কভার করার সম্ভাবনা থাকে (সমস্ত কলামগুলি প্রয়োজনীয় থাকে)। একটি দিয়ে SELECT *, আপনি ঠিক সেই সম্ভাবনাটি ছাড়ার সময় থেকেই ছেড়ে দিচ্ছেন। এই বিশেষ ক্ষেত্রে, সূচী পৃষ্ঠাগুলি থেকে ডেটা পুনরুদ্ধার করা হবে (যদি সেগুলিতে সমস্ত প্রয়োজনীয় কলাম থাকে) এবং এইভাবে ডিস্ক আই / ও এবং মেমরির ওভারহেড একটি SELECT *....কোয়েরি করার তুলনায় অনেক কম হবে ।

হ্যাঁ, এটি প্রথমে কিছুটা বেশি টাইপ করে নিবে ( এসকিউএল সার্ভারের জন্য এসকিউএল প্রম্পটের মতো সরঞ্জামগুলি আপনাকে সেখানে সহায়তা করবে) - তবে এটি সত্যিই এমন একটি ক্ষেত্রে যেখানে কোনও ব্যতিক্রম ছাড়াই একটি বিধি রয়েছে: আপনার উত্পাদন কোডে কখনও নির্বাচন করুন না। কখনোই না।

— marc_s
সূত্র

13

বাস্তবে আপনার সাথে একমত হওয়ার পরেও, টেবিল থেকে কলামের ডেটা আনার সময় আপনি অবশ্যই সব ক্ষেত্রে সঠিক, যেমন এই প্রশ্নটির ঠিকানা হিসাবে), তবুও সর্বদা এর উপর জোর দেওয়া আমাকে এই বিষয়টির দিকে লক্ষ্য করতে পরিচালিত করে যে এই বিধিগুলি সমস্ত স্ক্যাল কোয়েরিতে সাধারণ নয় .. বিশেষত, এটি একটি বিদ্যমান উপস্থাপকের পরে একটি subquery ব্যবহার, (হিসাবে হিসাবে Where Exists (Select * From ...) Select *অবশ্যই ব্যবহার কোন সমস্যা হয় না, এবং কিছু বৃত্তে সেরা অভ্যাস হিসাবে বিবেচিত হয়।

— চার্লস ব্রেটানা

3

@ চার্লস ব্রেটানা: হ্যাঁ, এটি IF EXISTS(SELECT *...একটি বিশেষ কেস - যেহেতু কোনও তথ্য সত্যই পুনরুদ্ধার করা হয়নি, তবে এটি কেবলমাত্র অস্তিত্বের জন্য একটি চেক,

— সেলেক্ট

1

আমি যদি এমন কোনও এপিআই বিকাশ করি যা আমার টেবিলে একটি থেকে ডেটা পুনরুদ্ধার করা সম্ভব করে। যেহেতু আমি জানব না যে ব্যবহারকারীটি কোন ডেটাতে আগ্রহী, তাই আমি মনে করি নির্বাচন নির্বাচন গ্রহণযোগ্য হবে?

— সাইমন বেঙ্গস্টসন

1

@ সিমোনবেগটসন: আমি এখনও এর বিরুদ্ধে তর্ক করব - ধরুন আপনার টেবিলের নির্দিষ্ট কলামগুলিতে এমন কিছু "প্রশাসনিক" ডেটা রয়েছে যা আপনি গ্রাহকের কাছে প্রকাশ করতে চান না? আমি সর্বদা স্পষ্টভাবে আনতে কলামগুলির তালিকা নির্দিষ্ট করব

— marc_s

1

সেটা সত্য. বিশেষত এপিআইয়ের সাথে ব্যবহারের জন্য সেটআপ করা একটি ভিউ জিজ্ঞাসা করার বিষয়ে কী হবে?

— সাইমন বেঙ্গস্টসন

21

আপনার অবশ্যই সর্বদা কেবল selectকলামগুলিই আপনার উচিত এটির পরিবর্তে কম নির্বাচন করা কখনই কম দক্ষ হয় না এবং আপনি কম অপ্রত্যাশিত পার্শ্ব প্রতিক্রিয়াগুলিতেও চলে যান - যেমন ক্লায়েন্টের সাথে সূচী দ্বারা আপনার ফলাফল কলামগুলি অ্যাক্সেস করা, তারপরে সেই সূচিগুলি টেবিলে একটি নতুন কলাম যুক্ত করে ভুল হয়ে যায়।

[সম্পাদনা]: অর্থ অ্যাক্সেস। বোকা মস্তিষ্ক এখনও জেগে আছে।

— ডনি
সূত্র

3

প্রান্তের ক্ষেত্রে +1 যা আমি বিশ্বাস করি না যে অনেকেই প্রথম নজরে ভাববেন না - ক্লায়েন্টের পক্ষের সূচি এবং যুক্ত / পরিবর্তিত কলাম।

— টমাস আসচান

1

হ্যাঁ, তবে কলামগুলির জন্য সংখ্যার সূচকগুলি কি সাধারণ? আমি ওআরএম ব্যবহার করে স্ট্রিং কী বা সম্পত্তি নাম ব্যবহার করে সর্বদা কলামের ডেটা অ্যাক্সেস করেছি।

— রাষ্ট্রদ্রোহিতা majesté

11

এটি অনেক দিন আগে দেখেছিলেন, জুনিয়র প্রোগ্রামার একটি টেবিল থেকে * নির্বাচন করেছেন এবং কলামের আদেশ সম্পর্কে অনুমান করেছিলেন; অন্য কেউ টেবিল পরিবর্তন করার সাথে সাথে তার সমস্ত কোডটি ভেঙে গেছে। আমাদের কী মজা ছিল।

— পল ম্যাককেঞ্জি

7

কেবল কোড পঠনযোগ্যতার জন্য সাধারণভাবে কলাম ক্রম ব্যবহার করা এটির পক্ষে খারাপ ধারণা SELECT *it

— লজ মেজেস্টে

2

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

— ম্যাট পিটারসন

7

আপনি যদি বড় ব্লব সংরক্ষণ না করেন তবে কর্মক্ষমতা কোনও উদ্বেগের বিষয় নয়। SELECT * ব্যবহার না করার বড় কারণ হ'ল আপনি যদি ফিরে আসা সারিগুলিকে টিপলস হিসাবে ব্যবহার করেন তবে কলামগুলি স্কিমাটি নির্দিষ্ট করতে যেভাবেই ঘটবে তা ফিরে আসবে, এবং যদি এটি পরিবর্তন হয় তবে আপনাকে আপনার সমস্ত কোড ঠিক করতে হবে।

অন্যদিকে, আপনি যদি অভিধান-স্টাইল অ্যাক্সেস ব্যবহার করেন তবে কলামগুলি কী অর্ডার ফিরে আসবে তা বিবেচ্য নয় কারণ আপনি সর্বদা নাম দ্বারা এগুলি অ্যাক্সেস করছেন।

— gxti
সূত্র

6

এটি অবিলম্বে আমাকে এমন একটি টেবিলের কথা ভাবতে বাধ্য করে যা আমি ব্যবহার করছিলাম যার মধ্যে একটি কলামের টাইপ রয়েছে blob; এটিতে সাধারণত একটি জেপিইজি চিত্র থাকে, কয়েকটি Mbআকারের।

SELECTআমি সত্যিই এটির প্রয়োজন না হলে আমি সেই কলামটি করিনি তা বলাই বাহুল্য । চারপাশে ভাসমান তথ্য থাকা - বিশেষত যখন আমি বহুগুণ সারি নির্বাচন করি - তখন কেবল একটি ঝামেলা ছিল।

তবে, আমি স্বীকার করব যে আমি অন্যথায় একটি টেবিলের সমস্ত কলামের জন্য সাধারণত জিজ্ঞাসা করি।

— রিচার্ড জেপি লে গুয়েন
সূত্র

20

এলওবি কলামগুলি সর্বদা SELECT * এর বিপদগুলির আমার প্রিয় উদাহরণ। আমি তৃতীয় অনুচ্ছেদটি না পড়া পর্যন্ত আমি আপনাকে উত্সাহ দিতে চলেছিলাম। টিএসকি, এসএসকে যদি অন্য কোনও বিকাশকারী কোনও টেবিলটিতে একটি বিএলওবি যোগ করেন তবে বর্তমানে এমন কলাম নেই?

— এপিসি

1

@ এপিসি, আমি আশা করি আমি আপনার মন্তব্য আরও উত্সাহ দিতে পারে। আপনার দরিদ্র সহকর্মীর কথা চিন্তা করুন যিনি একটি বিশাল পারফরম্যান্স মন্দার কারণ না করে কেবল একটি কলাম যুক্ত করতে চান! আপনার নির্দোষ চেহারা দেখার কয়েক ঘন্টা পরে তারা আবিষ্কার করলে তারা কতটা রেগে যাবে তা ভেবে দেখুন।

— মাইক শেরভ

1

@ ব্যবহারকারী 256007, হ্যাঁ, এমনকি বিএলএববিহীন ... বিএলওবি চরম উদাহরণটি বর্ণনা করে। চার্লসের প্রতি আমার প্রতিক্রিয়া পরীক্ষা করে দেখুন, এমন সময় আসে যখন নির্দিষ্ট কলামগুলি নির্বাচন করা আপনাকে ডিস্কে না গিয়েও মেমরি থেকে ডেটা ধরতে সক্ষম করতে পারে!

— মাইক শেরভ

1

@ রিচার্ড, আমি মনে করি যে তারা যখন ডিবির পারফরম্যান্সকে অনুকূল করে তোলেন তখন তারা আপনার পক্ষে সবচেয়ে বড় বিষয়, যা সময়ের 99% নয়। বেশিরভাগ ফ্রেমওয়ার্কগুলির মতো, খাঁটি পারফরম্যান্সের ত্যাগ করার সময় তারা দ্রুত বিকাশের জন্য জিনিসগুলিকে সাধারণীকরণের ঝোঁক দেয়। যেমন নুথ বলেছিলেন: "অকালীন অপটিমাইজেশন হ'ল সমস্ত মন্দের মূল" root যখন আপনি সেই বিন্দুতে পৌঁছে যান যেখানে আপনাকে নির্বাচিত কলামগুলির কার্যকারিতা সম্পর্কে চিন্তা করতে হবে select নির্বাচন করুন *, (আরআর সম্পর্কে টুইটারকে জিজ্ঞাসা করুন) আপনি এটি সম্পর্কে উদ্বিগ্ন হতে পারেন এবং এটি তখনই অনুকূলিত করতে পারেন। যদি ফ্রেমওয়ার্কটি এটি সমর্থন করার জন্য যথেষ্ট শক্তিশালী না হয় তবে আমি বলব আপনি ভুল ফ্রেমওয়ার্কটি ব্যবহার করছেন।

— মাইক শেরভ

1

@ ব্যবহারকারী 256007 - সাধারণ নিয়মটি হল "নির্বাচন করুন * 'ব্যবহার করবেন না mar মারক_স এর উত্তরটিতে কেন পুনরায় ঘটনাটি তা আবার নতুন করে দেখানো হয়েছে।

— এপিসি

6

এসকিউএল নির্বাচনের সময়, ডিবি সর্বদা টেবিলের জন্য মেটাডেটা উল্লেখ করতে চলেছে, এটি নির্বাচন করুন, খ, সি এর জন্য নির্বাচন করুন কিনা তা নির্বিশেষে ... কেন? সিস্টেমে টেবিলের কাঠামো এবং বিন্যাসের তথ্য যেখানে রয়েছে সেটিকেই বোকাও।

এটি দুটি কারণে এই তথ্যটি পড়তে হবে। এক, কেবল বিবৃতি সংকলন করতে। এটি খুব কম সময়ে একটি বিদ্যমান টেবিল নির্দিষ্ট করেছেন তা নিশ্চিত করা দরকার make এছাড়াও, শেষবারের মতো একটি বিবৃতি কার্যকর করার পরে ডাটাবেস কাঠামো পরিবর্তিত হতে পারে।

এখন, স্পষ্টতই, ডিবি মেটাডেটা সিস্টেমে ক্যাশে হয়েছে, তবে এটি এখনও প্রক্রিয়াজাত করা দরকার যা করা দরকার।

এরপরে, মেটাডেটা ক্যোয়ারী প্ল্যান উত্পন্ন করতে ব্যবহৃত হয়। প্রতিবার বিবৃতি সংকলিত হওয়ার পরে এটি ঘটে। আবার এটি ক্যাশেড মেটাডেটার বিরুদ্ধে চলে তবে সর্বদা তা হয়ে যায়।

কেবলমাত্র যখন এই প্রক্রিয়াকরণটি করা হয় না যখন DB প্রাক-সংকলিত ক্যোয়ারী ব্যবহার করে, বা কোনও পূর্ববর্তী ক্যোয়ারী ক্যাশে করে। এটি আক্ষরিক এসকিউএল পরিবর্তে বাঁধাই পরামিতি ব্যবহার করার পক্ষে যুক্তি। "টেবিলে কোথা থেকে সিলেক্ট করুন = 1" "টেবিলে কোথা থেকে কী নির্বাচন করুন = থেকে আলাদা?" এবং "1" কলটিতে আবদ্ধ।

ডিবিগুলি সেখানে কাজ করার জন্য পৃষ্ঠার ক্যাশেগুলিতে প্রচুর নির্ভর করে। অনেকগুলি আধুনিক ডিবি যথেষ্ট মেমরির মধ্যে পুরোপুরি ফিট করার জন্য ছোট (বা, সম্ভবত আমার বলা উচিত, আধুনিক স্মৃতি অনেকগুলি ডিবি ফিট করার পক্ষে যথেষ্ট বড়)। তারপরে পিছনের প্রান্তে আপনার প্রাথমিক I / O খরচ লগিং এবং পৃষ্ঠা ফ্লাশ হয় us

তবে, আপনি যদি এখনও আপনার ডিবি-র জন্য ডিস্কটিকে আঘাত করে থাকেন তবে অনেকগুলি সিস্টেমের দ্বারা করা প্রাথমিক অপ্টিমাইজেশন হ'ল টেবিলগুলি না করে সূচকগুলিতে থাকা ডেটাগুলির উপর নির্ভর করা।

যদি তোমার থাকে:

CREATE TABLE customer (
    id INTEGER NOT NULL PRIMARY KEY,
    name VARCHAR(150) NOT NULL,
    city VARCHAR(30),
    state VARCHAR(30),
    zip VARCHAR(10));

CREATE INDEX k1_customer ON customer(id, name);

তারপরে আপনি যদি "নির্বাচন করুন আইডি, গ্রাহকের নাম WHERE id = 1" করেন তবে খুব সম্ভবত আপনি ডিবি টেবিলের পরিবর্তে সূচি থেকে এই ডেটাটি টানবেন।

কেন? এটি সম্ভবত ক্যোরিয়াকে সন্তুষ্ট করতে সূচকটি ব্যবহার করবে (বনাম একটি টেবিল স্ক্যান), এবং যদিও 'নাম' যেখানে ধারাটিতে ব্যবহার করা হয়নি, সেই সূচীটি এখনও ক্যোয়ারির জন্য সেরা বিকল্প হবে।

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

এটি কয়েকটি ডেটাবেস দ্বারা ব্যবহৃত নির্দিষ্ট অপ্টিমাইজেশান কৌশলটির হ্যান্ড ওয়েভির ব্যাখ্যা। অনেকের কাছে বেশ কয়েকটি অপ্টিমাইজেশন এবং সুর করার কৌশল রয়েছে।

শেষ পর্যন্ত, আপনার নিজের হাতে টাইপ করতে হবে এমন ডায়নামিক ক্যোয়ারীগুলির জন্য নির্বাচন করুন * দরকারী, আমি কখনই এটি "রিয়েল কোড" এর জন্য ব্যবহার করব না। স্বতন্ত্র কলামগুলির সনাক্তকরণ ডিবিকে আরও তথ্য দেয় যা এটি কোয়েরিটি অনুকূলিত করতে ব্যবহার করতে পারে এবং স্কিমা পরিবর্তনের বিরুদ্ধে আপনার কোডগুলিতে আপনাকে আরও ভাল নিয়ন্ত্রণ প্রদান করে etc.

— উইল হার্টুং
সূত্র

উইল, আমি আপনার উত্তরটিকে অগ্রাহ্য করেছি, কেবলমাত্র আপনি মূল কী সহ কিছু ব্যবহার করেন না। আপনার পক্ষে এইভাবে লেখার কোনও ভাল কারণ আছে?

— শিক্ষার্থী

4

আমি মনে করি আপনার প্রশ্নের সঠিক কোনও উত্তর নেই, কারণ আপনার অ্যাপ্লিকেশনগুলি বজায় রাখার সুবিধা রয়েছে। Select columnআরও পারফরম্যাটিক select *তবে এটি যদি আপনি একটি ওরিয়েন্টেড অবজেক্ট সিস্টেম বিকাশ করে থাকেন তবে আপনার ব্যবহারটি পছন্দ হবে object.propertiesএবং অ্যাপ্লিকেশনগুলির যে কোনও অংশে আপনার একটি বৈশিষ্ট্যের প্রয়োজন হতে পারে, তবে বিশেষ পরিস্থিতিতে সম্পত্তি অর্জনের জন্য আপনাকে আরও পদ্ধতি লিখতে হবে যদি আপনি না করেন select *সমস্ত সম্পত্তি ব্যবহার এবং পপুলেট করুন। আপনার অ্যাপ্লিকেশনগুলি ব্যবহার করে একটি ভাল পারফরম্যান্স প্রয়োজন select *এবং কিছু ক্ষেত্রে আপনার কার্য সম্পাদন উন্নত করতে নির্বাচিত কলাম ব্যবহার করতে হবে column তারপরে আপনার কাছে পারফরম্যান্সের দরকার পড়লে অ্যাপ্লিকেশন এবং পারফরম্যান্স লিখতে এবং বজায় রাখার জন্য আপনার কাছে দুটি পৃথিবীর উন্নতি হবে।

— M.Torres
সূত্র

4

এখানে গৃহীত উত্তরটি ভুল। আমি এটি পেরিয়ে এসেছি যখন অন্য একটি প্রশ্ন এর সদৃশ হিসাবে বন্ধ করা হয়েছিল (যখন আমি এখনও আমার উত্তর লিখছিলাম - grr - সুতরাং এসকিউএল নীচে অন্য প্রশ্নের উল্লেখ করে)।

আপনার সর্বদা নির্বাচন করা বৈশিষ্ট্য, গুণাবলী ব্যবহার করা উচিত .... নির্বাচন না করুন *

এটি মূলত পারফরম্যান্স সমস্যার জন্য।

ব্যবহারকারীদের নাম নির্বাচন করুন নাম = 'জন';

খুব দরকারী উদাহরণ নয়। পরিবর্তে বিবেচনা করুন:

SELECT telephone FROM users WHERE name='John';

যদি কোনও সূচক (নাম, টেলিফোন) থাকে তবে সারণী থেকে প্রাসঙ্গিক মানগুলি অনুসন্ধান না করেই প্রশ্নের সমাধান করা যেতে পারে - একটি আচ্ছাদন সূচক রয়েছে।

আরও, ধরুন যে টেবিলটিতে ব্যবহারকারীর একটি ছবি, এবং একটি আপলোড করা সিভি, এবং একটি স্প্রেডশিট সমন্বিত একটি বিএলওবি রয়েছে ... নির্বাচন * ব্যবহার করে ডিবিএমএস বাফারগুলিতে (ক্যাশে থেকে অন্যান্য দরকারী তথ্য জোর করে) ফিরিয়ে দেওয়া হবে all তারপরে এগুলি সমস্ত অপ্রয়োজনীয় ডেটার জন্য ক্লায়েন্টের নেটওয়ার্ক এবং মেমরির উপরে সময় ব্যবহার করে ক্লায়েন্টকে প্রেরণ করা হবে।

ক্লায়েন্ট যদি একটি গণিত অ্যারে হিসাবে ডেটা পুনরুদ্ধার করে (যেমন পিএইচপি এর মাইএসকিএল_ফেটচ_আরে ($ এক্স, এমওয়াইএসকিউএল_এনএম)) এটি কার্যকরী সমস্যা তৈরি করতে পারে। কোডটি যখন 'টেলিফোন' লেখা ছিল সেলেক্ট * ফেরত পাঠানো তৃতীয় কলাম ছিল, তবে তারপরে কেউ এসে টেবিলে একটি ইমেল ঠিকানা যুক্ত করার সিদ্ধান্ত নিয়েছে, 'টেলিফোন' এর আগে অবস্থিত। কাঙ্ক্ষিত ক্ষেত্রটি এখন চতুর্থ কলামে স্থানান্তরিত হয়েছে।

— symcbean
সূত্র

2

উপায় যেভাবেই করার জন্য কারণ রয়েছে। আমি পোস্টগ্রেএসকিউএলএই * অনেকগুলি নির্বাচন করি কারণ পোস্টগ্রিজ এসকিউএলএ আপনি SELECT * এর সাথে অনেক কিছুই করতে পারেন যা আপনি একটি স্পষ্ট কলাম তালিকার সাথে করতে পারবেন না, বিশেষত সঞ্চিত পদ্ধতিতে যখন। একইভাবে ইনফর্মিক্সে, উত্তরাধিকার সূত্রে প্রাপ্ত টেবিল গাছের ওপরে নির্বাচন করুন আপনাকে জাজযুক্ত সারি দিতে পারে যখন একটি স্পষ্ট কলাম তালিকাটি চাইল্ড টেবিলে অতিরিক্ত কলামগুলি পাশাপাশি ফিরে আসে cannot

পোস্টগ্র্রেএসকিউএল এ আমি কেন এটির প্রধান কারণ হ'ল এটি নিশ্চিত করে যে আমি একটি সারণী নির্দিষ্ট করে একটি সুগঠিত টাইপ পেয়েছি। এটি আমাকে ফলাফল নিতে এবং সেগুলি পোস্টগ্রাইএসকিউএলে টেবিলের ধরণ হিসাবে ব্যবহার করতে দেয় allows এটি একটি অনমনীয় কলাম তালিকার চেয়ে ক্যোয়ারিতে আরও অনেক বিকল্পের অনুমতি দেয়।

অন্যদিকে, একটি অনমনীয় কলাম তালিকা আপনাকে একটি অ্যাপ্লিকেশন-স্তরের চেক দেয় যে ডিবি স্কিমার নির্দিষ্ট উপায়ে পরিবর্তন হয়নি এবং এটি সহায়ক হতে পারে। (আমি এই ধরনের চেক অন্য স্তরেও করি))

পারফরম্যান্সের জন্য, আমি ভিউ এবং স্টোরেজ পদ্ধতিগুলি রিটার্নিং প্রকারগুলি (এবং তারপরে সঞ্চিত পদ্ধতির অভ্যন্তরে একটি কলাম তালিকা) ব্যবহার করি tend এটি আমাকে কী ধরণের ফিরে আসে তার উপর নিয়ন্ত্রণ দেয়।

তবে মনে রাখবেন আমি বেস টেবিলের চেয়ে সাধারণত বিমূর্ত স্তরটির বিরুদ্ধে নির্বাচন করুন * নির্বাচন করুন।

— ক্রিস ট্র্যাভারস
সূত্র

2

এই নিবন্ধ থেকে রেফারেন্স নেওয়া:

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

নির্বাচন * সহ: যদি আপনার বিশেষ প্রয়োজনীয়তা থাকে এবং গতিশীল পরিবেশ তৈরি হয় তবে অ্যাপ্লিকেশন কোড দ্বারা স্বয়ংক্রিয়ভাবে কলাম যুক্ত বা মুছুন delete এই বিশেষ ক্ষেত্রে আপনাকে অ্যাপ্লিকেশন এবং ডাটাবেস কোড পরিবর্তন করতে হবে না এবং এটি স্বয়ংক্রিয়ভাবে উত্পাদন পরিবেশে প্রভাব ফেলবে। এই ক্ষেত্রে আপনি "নির্বাচন করুন" ব্যবহার করতে পারেন।

— Anvesh
সূত্র

0

আমি এখানে যে আলোচনার মুখ দেখছি না তাতে কেবল একটি সংজ্ঞা যোগ করার জন্য: I / O এর পরিপ্রেক্ষিতে, আপনি যদি কলাম-ভিত্তিক স্টোরেজ সহ একটি ডাটাবেস ব্যবহার করছেন তবে আপনি কেবলমাত্র কিছু অনুসন্ধানের জন্য যদি খুব বেশি I / O করতে পারেন কলাম. আমরা এসএসডি-তে যাওয়ার সাথে সাথে সুবিধাগুলি কিছুটা ছোট বনাম সারি-ভিত্তিক স্টোরেজ হতে পারে তবে একটি রয়েছে) কেবলমাত্র ব্লকগুলি পড়তে আপনার কলামগুলি অন্তর্ভুক্ত থাকে) খ) সংক্ষেপণ, যা সাধারণত ডিস্কে থাকা ডেটার আকারকে হ্রাস করে এবং তাই ডিস্ক থেকে পড়া ডেটা ভলিউম।

আপনি যদি কলাম-ভিত্তিক স্টোরেজটির সাথে পরিচিত না হন তবে পোস্টগ্রাসের জন্য একটি বাস্তবায়ন সিটাস ডেটা থেকে আসে, অন্যটি গ্রিনপ্লাম, অন্য প্যারাসেল, অন্যটি (স্বাচ্ছন্দ্যে) হলেন আমাজন রেডশিফ্ট। মাইএসকিউএল-এর জন্য ইনফোব্রাইট রয়েছে, এখনই নিকটতম ইনফিনিডিবি D অন্যান্য বাণিজ্যিক অফারগুলির মধ্যে এইচপি, সিবাস আইকিউ, টেরাদাতা থেকে ভার্টিকা অন্তর্ভুক্ত রয়েছে ...

— কার্নট আন্তোনিও রোমেরো
সূত্র

-1

select * from table1 INTERSECT  select * from table2

সমান

select distinct t1 from table1 where Exists (select t2 from table2 where table1.t1 = t2 )

— মেহেদী সাদেগী
সূত্র

আপনি কি দয়া করে আপনার কোডটি হাইলাইট করে এবং

— সিটিআরটি