C#.NET-এ LINQ প্রশ্নগুলি অপ্টিমাইজ করার পদ্ধতি

ভূমিকা

В এই নিবন্ধটি কিছু অপ্টিমাইজেশান পদ্ধতি বিবেচনা করা হয় LINQ প্রশ্ন.
এখানে আমরা কোড অপ্টিমাইজেশন সম্পর্কিত আরও কিছু পন্থা উপস্থাপন করি LINQ প্রশ্ন.

এটা জানা যায় লিনকুই(Language-Integrated Query) একটি তথ্য উৎস অনুসন্ধানের জন্য একটি সহজ এবং সুবিধাজনক ভাষা।

А SQL থেকে LINQ একটি ডিবিএমএসে ডেটা অ্যাক্সেস করার জন্য একটি প্রযুক্তি। এটি ডেটা নিয়ে কাজ করার জন্য একটি শক্তিশালী টুল, যেখানে একটি ঘোষণামূলক ভাষার মাধ্যমে প্রশ্নগুলি তৈরি করা হয়, যা পরে রূপান্তরিত হবে এসকিউএল প্রশ্ন প্ল্যাটফর্ম এবং এক্সিকিউশনের জন্য ডাটাবেস সার্ভারে পাঠানো হয়েছে। আমাদের ক্ষেত্রে, DBMS দ্বারা আমরা বোঝায় এমএস এসকিউএল সার্ভার.

যাইহোক, LINQ প্রশ্ন সর্বোত্তম লিখিত বেশী রূপান্তরিত হয় না এসকিউএল প্রশ্ন, যা একজন অভিজ্ঞ DBA অপ্টিমাইজেশানের সমস্ত সূক্ষ্মতা সহ লিখতে পারে৷ এসকিউএল প্রশ্ন:

1. সর্বোত্তম সংযোগ (JOIN) এবং ফলাফল ফিল্টারিং (কোথায়)
2. সংযোগ এবং গ্রুপ শর্তাবলী ব্যবহার করার অনেক সূক্ষ্মতা
3. শর্ত প্রতিস্থাপন অনেক বৈচিত্র IN উপর উপস্থিতи না, <> চালু উপস্থিত
4. অস্থায়ী টেবিল, CTE, টেবিল ভেরিয়েবলের মাধ্যমে ফলাফলের মধ্যবর্তী ক্যাশিং
5. বাক্যের ব্যবহার (অনুযায়ী OPTION) নির্দেশাবলী এবং টেবিল ইঙ্গিত সহ সঙ্গে (...)
6. নির্বাচনের সময় অপ্রয়োজনীয় ডেটা রিডিং থেকে পরিত্রাণ পাওয়ার অন্যতম উপায় হিসাবে সূচীকৃত ভিউ ব্যবহার করা

ফলে প্রধান কর্মক্ষমতা বাধা এসকিউএল প্রশ্ন কম্পাইল করার সময় LINQ প্রশ্ন এইগুলি হল:

1. একটি অনুরোধে সমগ্র ডেটা নির্বাচন প্রক্রিয়ার একত্রীকরণ
2. কোডের অনুরূপ ব্লকের নকল, যা শেষ পর্যন্ত একাধিক অপ্রয়োজনীয় ডেটা পড়ার দিকে নিয়ে যায়
3. মাল্টি-কম্পোনেন্ট অবস্থার গ্রুপ (যৌক্তিক "এবং" এবং "বা") - এবং и OR, জটিল অবস্থার মধ্যে একত্রিত করা, এই সত্যের দিকে পরিচালিত করে যে অপ্টিমাইজার, প্রয়োজনীয় ক্ষেত্রের জন্য উপযুক্ত নন-ক্লাস্টারড সূচক থাকা, শেষ পর্যন্ত ক্লাস্টারযুক্ত সূচকের বিরুদ্ধে স্ক্যান করা শুরু করে (ইনডেক্স স্ক্যান) শর্তের গ্রুপ দ্বারা
4. সাবকোয়েরির গভীর নেস্টিং পার্সিংকে খুব সমস্যাযুক্ত করে তোলে এসকিউএল বিবৃতি এবং ডেভেলপারদের পক্ষ থেকে ক্যোয়ারী প্ল্যানের বিশ্লেষণ এবং DBA

অনুকূলকরণ পদ্ধতি

এখন সরাসরি অপ্টিমাইজেশান পদ্ধতিতে যাওয়া যাক।

1) অতিরিক্ত ইনডেক্সিং

প্রধান নির্বাচন সারণীতে ফিল্টারগুলি বিবেচনা করা সর্বোত্তম, যেহেতু প্রায়শই পুরো ক্যোয়ারীটি এক বা দুটি প্রধান টেবিল (অ্যাপ্লিকেশন-লোক-অপারেশন) এবং শর্তগুলির একটি মানক সেট (IsClosed, Canceled, Enabled, Status) এর চারপাশে তৈরি করা হয়। চিহ্নিত নমুনার জন্য উপযুক্ত সূচক তৈরি করা গুরুত্বপূর্ণ।

এই ক্ষেত্রগুলি নির্বাচন করার সময় এই সমাধানটি বোধগম্য হয় যখন প্রশ্নে ফিরে আসা সেটটিকে উল্লেখযোগ্যভাবে সীমাবদ্ধ করে।

উদাহরণস্বরূপ, আমাদের 500000 অ্যাপ্লিকেশন রয়েছে। যাইহোক, শুধুমাত্র 2000 সক্রিয় অ্যাপ্লিকেশন আছে। তারপর একটি সঠিকভাবে নির্বাচিত সূচক আমাদের থেকে রক্ষা করবে ইনডেক্স স্ক্যান একটি বড় টেবিলে এবং আপনাকে একটি নন-ক্লাস্টারড সূচকের মাধ্যমে দ্রুত ডেটা নির্বাচন করার অনুমতি দেবে।

এছাড়াও, ক্যোয়ারী প্ল্যান পার্সিং বা সিস্টেম ভিউ পরিসংখ্যান সংগ্রহের জন্য প্রম্পটের মাধ্যমে সূচকের অভাব চিহ্নিত করা যেতে পারে এমএস এসকিউএল সার্ভার:

1. sys.dm_db_missing_index_groups
2. sys.dm_db_missing_index_group_stats
3. sys.dm_db_missing_index_details

সমস্ত ভিউ ডেটাতে স্থানিক সূচকগুলি বাদ দিয়ে অনুপস্থিত সূচীগুলির সম্পর্কে তথ্য রয়েছে৷

যাইহোক, সূচী এবং ক্যাশিং প্রায়শই খারাপভাবে লেখার পরিণতিগুলির বিরুদ্ধে লড়াই করার পদ্ধতি LINQ প্রশ্ন и এসকিউএল প্রশ্ন.

জীবনের কঠোর অনুশীলন দেখায়, একটি ব্যবসার জন্য নির্দিষ্ট সময়সীমার মধ্যে ব্যবসার বৈশিষ্ট্যগুলি বাস্তবায়ন করা প্রায়শই গুরুত্বপূর্ণ। এবং সেইজন্য, ভারী অনুরোধগুলি প্রায়ই ক্যাশিং সহ পটভূমিতে স্থানান্তরিত হয়।

এটি আংশিকভাবে ন্যায়সঙ্গত, যেহেতু ব্যবহারকারীর সর্বদা সর্বশেষ ডেটার প্রয়োজন হয় না এবং ব্যবহারকারীর ইন্টারফেসের প্রতিক্রিয়াশীলতার একটি গ্রহণযোগ্য স্তর রয়েছে।

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

এটা মনে রাখা মূল্যবান যে প্রয়োজনীয় সূচী অনুসন্ধানের প্রক্রিয়ার মধ্যে যোগ করার জন্য, পরামর্শ এমএস এসকিউএল অপ্টিমাইজেশান ভুল হতে পারে, নিম্নলিখিত শর্তাবলী সহ:

1. যদি ইতিমধ্যেই ক্ষেত্রগুলির একটি অনুরূপ সেট সহ সূচী থাকে
2. যদি টেবিলের ক্ষেত্রগুলি ইন্ডেক্সিং সীমাবদ্ধতার কারণে সূচিত করা না যায় (আরো বিস্তারিতভাবে বর্ণনা করা হয়েছে) এখানে).

2) বৈশিষ্ট্যগুলিকে একটি নতুন বৈশিষ্ট্যে একত্রিত করা৷

কখনও কখনও একটি টেবিল থেকে কিছু ক্ষেত্র, যা শর্তগুলির একটি গ্রুপের ভিত্তি হিসাবে কাজ করে, একটি নতুন ক্ষেত্র প্রবর্তন করে প্রতিস্থাপন করা যেতে পারে।

এটি স্ট্যাটাস ক্ষেত্রগুলির জন্য বিশেষভাবে সত্য, যেগুলি সাধারণত বিট বা পূর্ণসংখ্যার হয়।

উদাহরণ:

বন্ধ = 0 এবং বাতিল = 0 এবং সক্ষম = 0 দ্বারা প্রতিস্থাপিত হয় অবস্থা = 1.

এখানেই পূর্ণসংখ্যা স্থিতি বৈশিষ্ট্যটি চালু করা হয়েছে যাতে নিশ্চিত করা হয় যে এই স্ট্যাটাসগুলি সারণিতে রয়েছে। পরবর্তী, এই নতুন বৈশিষ্ট্য সূচিত করা হয়.

এটি কর্মক্ষমতা সমস্যার একটি মৌলিক সমাধান, কারণ আমরা অপ্রয়োজনীয় গণনা ছাড়াই ডেটা অ্যাক্সেস করি।

3) দৃশ্যের বস্তুগতীকরণ

দুর্ভাগ্যবশত LINQ প্রশ্ন অস্থায়ী টেবিল, CTE, এবং টেবিল ভেরিয়েবল সরাসরি ব্যবহার করা যাবে না।

যাইহোক, এই ক্ষেত্রে অপ্টিমাইজ করার আরেকটি উপায় আছে - সূচীকৃত ভিউ।

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

কিন্তু একটি দৃশ্য বাস্তবায়িত করার সময় বেশ কিছু বিধিনিষেধ রয়েছে:

1. subqueries ব্যবহার, ধারা উপস্থিত ব্যবহার করে প্রতিস্থাপন করা উচিত JOIN
2. আপনি বাক্য ব্যবহার করতে পারবেন না মিলন, ইউনিয়ন সব, ছাড়, ইন্টারস্যাক্ট
3. আপনি টেবিল ইঙ্গিত এবং ধারা ব্যবহার করতে পারবেন না অনুযায়ী OPTION
4. চক্রের সাথে কাজ করার কোন সম্ভাবনা নেই
5. বিভিন্ন টেবিল থেকে এক ভিউতে ডেটা প্রদর্শন করা অসম্ভব

এটা মনে রাখা গুরুত্বপূর্ণ যে একটি সূচীকৃত দৃশ্য ব্যবহার করার প্রকৃত সুবিধা শুধুমাত্র প্রকৃতপক্ষে সূচীকরণের মাধ্যমে অর্জন করা যেতে পারে।

কিন্তু একটি ভিউ কল করার সময়, এই সূচীগুলি ব্যবহার করা যাবে না, এবং স্পষ্টভাবে ব্যবহার করার জন্য, আপনাকে অবশ্যই নির্দিষ্ট করতে হবে সঙ্গে (NOEXPAND).

১ Since সাল থেকে LINQ প্রশ্ন টেবিলের ইঙ্গিতগুলি সংজ্ঞায়িত করা অসম্ভব, তাই আপনাকে আরেকটি উপস্থাপনা তৈরি করতে হবে - নিম্নলিখিত ফর্মের একটি "র্যাপার":

CREATE VIEW ИМЯ_представления AS SELECT * FROM MAT_VIEW WITH (NOEXPAND);

4) টেবিল ফাংশন ব্যবহার করে

প্রায়ই মধ্যে LINQ প্রশ্ন সাবকোয়েরির বড় ব্লক বা একটি জটিল কাঠামোর ভিউ ব্যবহার করে ব্লকগুলি খুব জটিল এবং সাবঅপ্টিমাল এক্সিকিউশন স্ট্রাকচারের সাথে একটি চূড়ান্ত প্রশ্ন তৈরি করে।

মধ্যে টেবিল ফাংশন ব্যবহার করার মূল সুবিধা LINQ প্রশ্ন:

1. ক্ষমতা, দৃশ্যের ক্ষেত্রে, একটি বস্তু হিসাবে ব্যবহার এবং নির্দিষ্ট করার জন্য, কিন্তু আপনি ইনপুট পরামিতিগুলির একটি সেট পাস করতে পারেন:
   ফাংশন থেকে (@param1, @param2 ...)
   ফলস্বরূপ, নমনীয় ডেটা স্যাম্পলিং অর্জন করা যেতে পারে
2. একটি টেবিল ফাংশন ব্যবহার করার ক্ষেত্রে, উপরে বর্ণিত সূচীকৃত দৃশ্যের ক্ষেত্রে এমন কোন শক্তিশালী বিধিনিষেধ নেই:
   1. টেবিল ইঙ্গিত:
      দ্বারা লিনকুই আপনি কোন সূচী ব্যবহার করা উচিত তা নির্দিষ্ট করতে পারবেন না এবং অনুসন্ধান করার সময় ডেটা বিচ্ছিন্নতা স্তর নির্ধারণ করতে পারবেন না।
      কিন্তু ফাংশন এই ক্ষমতা আছে.
      ফাংশনের সাহায্যে, আপনি একটি মোটামুটি ধ্রুবক এক্সিকিউশন ক্যোয়ারী প্ল্যান অর্জন করতে পারেন, যেখানে ইনডেক্স এবং ডেটা আইসোলেশন লেভেলগুলির সাথে কাজ করার নিয়মগুলি সংজ্ঞায়িত করা হয়
   2. ফাংশন ব্যবহার করে, সূচীকৃত দৃশ্যের সাথে তুলনা করে, প্রাপ্ত করার অনুমতি দেয়:
      • জটিল ডেটা স্যাম্পলিং লজিক (এমনকি লুপ ব্যবহার করে)
      • বিভিন্ন টেবিল থেকে ডেটা আনা হচ্ছে
      • ব্যবহারের মিলন и উপস্থিত

3. প্রদান অনুযায়ী OPTION যখন আমাদের একযোগে নিয়ন্ত্রণ প্রদান করতে হয় তখন খুব দরকারী বিকল্প (MAXDOP N), ক্যোয়ারী এক্সিকিউশন প্ল্যানের ক্রম। উদাহরণ স্বরূপ:
   • আপনি ক্যোয়ারী পরিকল্পনার একটি জোরপূর্বক পুনঃসৃষ্টি নির্দিষ্ট করতে পারেন বিকল্প (পুনঃকম্পাইল)
   • আপনি ক্যোয়ারীতে উল্লেখিত যোগদানের আদেশ ব্যবহার করার জন্য ক্যোয়ারী প্ল্যানকে বাধ্য করবেন কিনা তা নির্দিষ্ট করতে পারেন বিকল্প (ফোর্স অর্ডার)

   সম্পর্কে আরো বিস্তারিত অনুযায়ী OPTION বর্ণিত এখানে.

4. সংকীর্ণ এবং সবচেয়ে প্রয়োজনীয় ডেটা স্লাইস ব্যবহার করে:
   ক্যাশে বড় ডেটা সেট সংরক্ষণ করার কোন প্রয়োজন নেই (যেমনটি সূচীকৃত ভিউয়ের ক্ষেত্রে), যেখান থেকে আপনাকে এখনও প্যারামিটার দ্বারা ডেটা ফিল্টার করতে হবে।
   উদাহরণস্বরূপ, একটি টেবিল আছে যার ফিল্টার কোথায় তিনটি ক্ষেত্র ব্যবহার করা হয় (a, b, c).

   প্রচলিতভাবে, সমস্ত অনুরোধের একটি ধ্রুবক অবস্থা আছে a = 0 এবং b = 0.

   তবে মাঠের জন্য অনুরোধ c আরো পরিবর্তনশীল।

   শর্ত যাক a = 0 এবং b = 0 এটা সত্যিই আমাদের প্রয়োজনীয় ফলাফল সেট হাজার হাজার রেকর্ড সীমিত করতে সাহায্য করে, কিন্তু শর্ত চালু আছে с নির্বাচনকে একশো রেকর্ডে সংকুচিত করে।

   এখানে টেবিল ফাংশন একটি ভাল বিকল্প হতে পারে.

   এছাড়াও, একটি টেবিল ফাংশন কার্যকর করার সময় আরও অনুমানযোগ্য এবং সামঞ্জস্যপূর্ণ।

উদাহরণ

আসুন একটি উদাহরণ হিসাবে প্রশ্ন ডাটাবেস ব্যবহার করে একটি উদাহরণ বাস্তবায়ন দেখি।

একটা অনুরোধ আছে নির্বাচন, যা বেশ কয়েকটি টেবিলকে একত্রিত করে এবং একটি ভিউ ব্যবহার করে (অপারেটিভ প্রশ্ন), যেখানে অধিভুক্তি ইমেল দ্বারা চেক করা হয় (এর মাধ্যমে উপস্থিত) থেকে "অপারেটিভ প্রশ্ন":

অনুরোধ নং 1

(@p__linq__0 nvarchar(4000))SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Join2].[Object_Id] AS [Object_Id],
[Join2].[ObjectType_Id] AS [ObjectType_Id],
[Join2].[Name] AS [Name],
[Join2].[ExternalId] AS [ExternalId]
FROM [dbo].[Questions] AS [Extent1]
INNER JOIN (SELECT [Extent2].[Object_Id] AS [Object_Id],
[Extent2].[Question_Id] AS [Question_Id], [Extent3].[ExternalId] AS [ExternalId],
[Extent3].[ObjectType_Id] AS [ObjectType_Id], [Extent4].[Name] AS [Name]
FROM [dbo].[ObjectQuestions] AS [Extent2]
INNER JOIN [dbo].[Objects] AS [Extent3] ON [Extent2].[Object_Id] = [Extent3].[Id]
LEFT OUTER JOIN [dbo].[ObjectTypes] AS [Extent4] 
ON [Extent3].[ObjectType_Id] = [Extent4].[Id] ) AS [Join2] 
ON [Extent1].[Id] = [Join2].[Question_Id]
WHERE ([Extent1].[AnswerId] IS NULL) AND (0 = [Extent1].[Exp]) AND ( EXISTS (SELECT
1 AS [C1]
FROM [dbo].[OperativeQuestions] AS [Extent5]
WHERE (([Extent5].[Email] = @p__linq__0) OR (([Extent5].[Email] IS NULL) 
AND (@p__linq__0 IS NULL))) AND ([Extent5].[Id] = [Extent1].[Id])
));

ভিউটির একটি বরং জটিল গঠন রয়েছে: এতে সাবকোয়েরি যোগ রয়েছে এবং বাছাই করা ব্যবহার করে স্বতন্ত্র, যা সাধারণভাবে একটি মোটামুটি সম্পদ-নিবিড় অপারেশন।

OperativeQuestions থেকে একটি নমুনা প্রায় দশ হাজার রেকর্ড.

এই ক্যোয়ারীটির প্রধান সমস্যা হল যে বাইরের ক্যোয়ারী থেকে রেকর্ডের জন্য, একটি অভ্যন্তরীণ সাবকোয়েরি [OperativeQuestions] ভিউতে কার্যকর করা হয়, যা [ইমেল] = @p__linq__0 এর জন্য আমাদের আউটপুট নির্বাচন সীমিত করতে দেয় (এর মাধ্যমে উপস্থিত) শত শত রেকর্ড পর্যন্ত।

এবং এটা মনে হতে পারে যে সাবকোয়েরির রেকর্ডগুলি একবার [ইমেল] = @p__linq__0 দ্বারা গণনা করা উচিত, এবং তারপর এই কয়েকশ রেকর্ডগুলিকে প্রশ্নগুলির সাথে আইডি দ্বারা সংযুক্ত করা উচিত এবং কোয়েরি দ্রুত হবে৷

প্রকৃতপক্ষে, সমস্ত টেবিলের একটি অনুক্রমিক সংযোগ রয়েছে: অপারেটিভ প্রশ্ন থেকে আইডির সাথে আইডি প্রশ্নের চিঠিপত্র পরীক্ষা করা এবং ইমেল দ্বারা ফিল্টার করা।

প্রকৃতপক্ষে, অনুরোধটি হাজার হাজার অপারেটিভ প্রশ্ন রেকর্ডের সাথে কাজ করে, তবে ইমেলের মাধ্যমে শুধুমাত্র আগ্রহের ডেটা প্রয়োজন।

অপারেটিভ প্রশ্ন পাঠ্য দেখুন:

অনুরোধ নং 2

 
CREATE VIEW [dbo].[OperativeQuestions]
AS
SELECT DISTINCT Q.Id, USR.email AS Email
FROM            [dbo].Questions AS Q INNER JOIN
                         [dbo].ProcessUserAccesses AS BPU ON BPU.ProcessId = CQ.Process_Id 
OUTER APPLY
                     (SELECT   1 AS HasNoObjects
                      WHERE   NOT EXISTS
                                    (SELECT   1
                                     FROM     [dbo].ObjectUserAccesses AS BOU
                                     WHERE   BOU.ProcessUserAccessId = BPU.[Id] AND BOU.[To] IS NULL)
) AS BO INNER JOIN
                         [dbo].Users AS USR ON USR.Id = BPU.UserId
WHERE        CQ.[Exp] = 0 AND CQ.AnswerId IS NULL AND BPU.[To] IS NULL 
AND (BO.HasNoObjects = 1 OR
              EXISTS (SELECT   1
                           FROM   [dbo].ObjectUserAccesses AS BOU INNER JOIN
                                      [dbo].ObjectQuestions AS QBO 
                                                  ON QBO.[Object_Id] =BOU.ObjectId
                               WHERE  BOU.ProcessUserAccessId = BPU.Id 
                               AND BOU.[To] IS NULL AND QBO.Question_Id = CQ.Id));

DbContext-এ প্রাথমিক ভিউ ম্যাপিং (EF কোর 2)

public class QuestionsDbContext : DbContext
{
    //...
    public DbQuery<OperativeQuestion> OperativeQuestions { get; set; }
    //...
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Query<OperativeQuestion>().ToView("OperativeQuestions");
    }
}

প্রাথমিক LINQ প্রশ্ন

var businessObjectsData = await context
    .OperativeQuestions
    .Where(x => x.Email == Email)
    .Include(x => x.Question)
    .Select(x => x.Question)
    .SelectMany(x => x.ObjectQuestions,
                (x, bo) => new
                {
                    Id = x.Id,
                    ObjectId = bo.Object.Id,
                    ObjectTypeId = bo.Object.ObjectType.Id,
                    ObjectTypeName = bo.Object.ObjectType.Name,
                    ObjectExternalId = bo.Object.ExternalId
                })
    .ToListAsync();

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

যদিও এটি একটি ভাল সমাধান, এই সমস্যাটি অপ্টিমাইজ করার আরেকটি বিকল্প রয়েছে।

মূল উদ্দেশ্য হল অপারেটিভ প্রশ্ন ভিউ থেকে [ইমেল] = @p__linq__0 দ্বারা এন্ট্রি ক্যাশে করা।

ডাটাবেসের মধ্যে টেবিল ফাংশন [ডিবিও] [অপারেটিভ প্রশ্ন ইউজারমেল] প্রবর্তন করুন।

একটি ইনপুট প্যারামিটার হিসাবে ইমেল পাঠানোর মাধ্যমে, আমরা মানগুলির একটি টেবিল ফিরে পাই:

অনুরোধ নং 3

CREATE FUNCTION [dbo].[OperativeQuestionsUserMail]
(
    @Email  nvarchar(4000)
)
RETURNS
@tbl TABLE
(
    [Id]           uniqueidentifier,
    [Email]      nvarchar(4000)
)
AS
BEGIN
        INSERT INTO @tbl ([Id], [Email])
        SELECT Id, @Email
        FROM [OperativeQuestions]  AS [x] WHERE [x].[Email] = @Email;
     
    RETURN;
END

এটি একটি পূর্বনির্ধারিত ডেটা স্ট্রাকচার সহ মানগুলির একটি টেবিল প্রদান করে।

OperativeQuestionsUserMail-এর প্রশ্নগুলি সর্বোত্তম হতে এবং সর্বোত্তম ক্যোয়ারী পরিকল্পনার জন্য, একটি কঠোর কাঠামোর প্রয়োজন, এবং নয় রিটার্ন হিসাবে টেবিল ফেরত...

এই ক্ষেত্রে, প্রয়োজনীয় ক্যোয়ারী 1 ক্যোয়ারী 4 এ রূপান্তরিত হয়:

অনুরোধ নং 4

(@p__linq__0 nvarchar(4000))SELECT
1 AS [C1],
[Extent1].[Id] AS [Id],
[Join2].[Object_Id] AS [Object_Id],
[Join2].[ObjectType_Id] AS [ObjectType_Id],
[Join2].[Name] AS [Name],
[Join2].[ExternalId] AS [ExternalId]
FROM (
    SELECT Id, Email FROM [dbo].[OperativeQuestionsUserMail] (@p__linq__0)
) AS [Extent0]
INNER JOIN [dbo].[Questions] AS [Extent1] ON([Extent0].Id=[Extent1].Id)
INNER JOIN (SELECT [Extent2].[Object_Id] AS [Object_Id], [Extent2].[Question_Id] AS [Question_Id], [Extent3].[ExternalId] AS [ExternalId], [Extent3].[ObjectType_Id] AS [ObjectType_Id], [Extent4].[Name] AS [Name]
FROM [dbo].[ObjectQuestions] AS [Extent2]
INNER JOIN [dbo].[Objects] AS [Extent3] ON [Extent2].[Object_Id] = [Extent3].[Id]
LEFT OUTER JOIN [dbo].[ObjectTypes] AS [Extent4] 
ON [Extent3].[ObjectType_Id] = [Extent4].[Id] ) AS [Join2] 
ON [Extent1].[Id] = [Join2].[Question_Id]
WHERE ([Extent1].[AnswerId] IS NULL) AND (0 = [Extent1].[Exp]);

DbContext (EF কোর 2) এ ম্যাপিং ভিউ এবং ফাংশন

public class QuestionsDbContext : DbContext
{
    //...
    public DbQuery<OperativeQuestion> OperativeQuestions { get; set; }
    //...
    protected override void OnModelCreating(ModelBuilder modelBuilder)
    {
        modelBuilder.Query<OperativeQuestion>().ToView("OperativeQuestions");
    }
}
 
public static class FromSqlQueries
{
    public static IQueryable<OperativeQuestion> GetByUserEmail(this DbQuery<OperativeQuestion> source, string Email)
        => source.FromSql($"SELECT Id, Email FROM [dbo].[OperativeQuestionsUserMail] ({Email})");
}

চূড়ান্ত LINQ প্রশ্ন

var businessObjectsData = await context
    .OperativeQuestions
    .GetByUserEmail(Email)
    .Include(x => x.Question)
    .Select(x => x.Question)
    .SelectMany(x => x.ObjectQuestions,
                (x, bo) => new
                {
                    Id = x.Id,
                    ObjectId = bo.Object.Id,
                    ObjectTypeId = bo.Object.ObjectType.Id,
                    ObjectTypeName = bo.Object.ObjectType.Name,
                    ObjectExternalId = bo.Object.ExternalId
                })
    .ToListAsync();

কার্য সম্পাদনের সময় 200-800 ms থেকে 2-20 ms, ইত্যাদিতে নেমে এসেছে, অর্থাৎ দশগুণ দ্রুত।

যদি আমরা এটিকে আরও গড়ভাবে নিই, তাহলে 350 ms এর পরিবর্তে আমরা 8 ms পেয়েছি।

সুস্পষ্ট সুবিধাগুলি থেকে আমরাও পাই:

1. পড়ার লোডের সাধারণ হ্রাস,
2. ব্লক করার সম্ভাবনা উল্লেখযোগ্য হ্রাস
3. গ্রহণযোগ্য মানগুলিতে গড় ব্লকিং সময় হ্রাস করা

উপসংহার

ডাটাবেস কলের অপ্টিমাইজেশন এবং ফাইন-টিউনিং এমএস এসকিউএল দ্বারা লিনকুই একটি সমস্যা যা সমাধান করা যেতে পারে।

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

প্রক্রিয়ার শুরুতে:

1. অনুরোধটি কাজ করে এমন ডেটা পরীক্ষা করা প্রয়োজন (মান, নির্বাচিত ডেটা প্রকার)
2. এই তথ্য সঠিক সূচী বহন
3. টেবিলের মধ্যে যোগদানের শর্তগুলির সঠিকতা পরীক্ষা করুন

পরবর্তী অপ্টিমাইজেশান পুনরাবৃত্তি প্রকাশ করে:

1. অনুরোধের ভিত্তিতে এবং প্রধান অনুরোধ ফিল্টার সংজ্ঞায়িত করে
2. অনুরূপ ক্যোয়ারী ব্লক পুনরাবৃত্তি এবং অবস্থার ছেদ বিশ্লেষণ
3. এর জন্য SSMS বা অন্য GUI-তে SQL সার্ভার নিজেকে অপ্টিমাইজ করে এসকিউএল কোয়েরি (একটি মধ্যবর্তী ডেটা সঞ্চয়স্থান বরাদ্দ করা, এই স্টোরেজ ব্যবহার করে ফলাফল ক্যোয়ারী তৈরি করা (এখানে বেশ কয়েকটি থাকতে পারে))
4. শেষ পর্যায়ে, একটি ভিত্তি হিসাবে গ্রহণ ফলাফল এসকিউএল কোয়েরি, কাঠামো পুনর্নির্মাণ করা হচ্ছে LINQ প্রশ্ন

ফলে LINQ প্রশ্ন চিহ্নিত অনুকূল থেকে গঠন অভিন্ন হতে হবে এসকিউএল কোয়েরি পয়েন্ট 3 থেকে।

স্বীকৃতি

সহকর্মীদের অনেক ধন্যবাদ jobgemws и alex_ozr কোম্পানি থেকে স্ট্রং এই উপাদান প্রস্তুত করতে সহায়তার জন্য।

উত্স: www.habr.com