C#.NET માં LINQ ક્વેરીઝને ઑપ્ટિમાઇઝ કરવા માટેની પદ્ધતિઓ

પરિચય

В આ લેખ કેટલીક ઓપ્ટિમાઇઝેશન પદ્ધતિઓ ધ્યાનમાં લેવામાં આવી હતી LINQ પ્રશ્નો.
અહીં અમે કોડ ઑપ્ટિમાઇઝેશન સંબંધિત કેટલાક વધુ અભિગમો પણ રજૂ કરીએ છીએ LINQ પ્રશ્નો.

તે જાણીતું છે કે LINQ(ભાષા-સંકલિત ક્વેરી) ડેટા સ્ત્રોતની ક્વેરી કરવા માટે એક સરળ અને અનુકૂળ ભાષા છે.

А LINQ થી SQL DBMS માં ડેટા એક્સેસ કરવા માટેની ટેકનોલોજી છે. ડેટા સાથે કામ કરવા માટે આ એક શક્તિશાળી સાધન છે, જ્યાં ક્વેરી એક ઘોષણાત્મક ભાષા દ્વારા બનાવવામાં આવે છે, જે પછી રૂપાંતરિત કરવામાં આવશે. SQL પ્રશ્નો પ્લેટફોર્મ અને અમલીકરણ માટે ડેટાબેઝ સર્વર પર મોકલવામાં આવે છે. અમારા કિસ્સામાં, DBMS દ્વારા અમારો અર્થ છે એમએસ એસક્યુએલ સર્વર.

જો કે, LINQ પ્રશ્નો શ્રેષ્ઠ રીતે લખેલામાં રૂપાંતરિત થતા નથી SQL પ્રશ્નો, જે એક અનુભવી DBA ઑપ્ટિમાઇઝેશનની તમામ ઘોંઘાટ સાથે લખી શકે છે SQL પ્રશ્નો:

1. શ્રેષ્ઠ જોડાણો (જોડાઓ) અને પરિણામોને ફિલ્ટર કરવું (ક્યાં છે)
2. જોડાણો અને જૂથ શરતોનો ઉપયોગ કરવામાં ઘણી ઘોંઘાટ
3. બદલવાની પરિસ્થિતિઓમાં ઘણી ભિન્નતા IN પર અસ્તિત્વમાં છેи માં નહિ, <> ચાલુ અસ્તિત્વમાં છે
4. અસ્થાયી કોષ્ટકો, CTE, કોષ્ટક ચલો દ્વારા પરિણામોનું મધ્યવર્તી કેશીંગ
5. વાક્યનો ઉપયોગ (વિકલ્પ) સૂચનો અને ટેબલ સંકેતો સાથે સાથે (...)
6. પસંદગી દરમિયાન બિનજરૂરી ડેટા રીડિંગ્સથી છુટકારો મેળવવાના એક માધ્યમ તરીકે અનુક્રમિત દૃશ્યોનો ઉપયોગ કરવો

પરિણામી મુખ્ય કામગીરી અવરોધો SQL પ્રશ્નો સંકલન કરતી વખતે 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 પ્રશ્નો и SQL પ્રશ્નો.

જીવનની કઠોર પ્રેક્ટિસ બતાવે છે તેમ, વ્યવસાય માટે ચોક્કસ સમયમર્યાદા દ્વારા વ્યવસાયિક વિશેષતાઓને અમલમાં મૂકવી ઘણી વખત મહત્વપૂર્ણ છે. અને તેથી, ભારે વિનંતીઓ ઘણીવાર કેશીંગ સાથે પૃષ્ઠભૂમિમાં સ્થાનાંતરિત થાય છે.

આ આંશિક રીતે ન્યાયી છે, કારણ કે વપરાશકર્તાને હંમેશા નવીનતમ ડેટાની જરૂર હોતી નથી અને વપરાશકર્તા ઇન્ટરફેસની પ્રતિભાવશીલતાનું સ્વીકાર્ય સ્તર છે.

આ અભિગમ વ્યવસાયિક જરૂરિયાતોને હલ કરવાની મંજૂરી આપે છે, પરંતુ આખરે સમસ્યાઓના ઉકેલોમાં વિલંબ કરીને માહિતી પ્રણાલીની કામગીરીને ઘટાડે છે.

તે યાદ રાખવું પણ યોગ્ય છે કે ઉમેરવા માટે જરૂરી સૂચકાંકો શોધવાની પ્રક્રિયામાં, સૂચનો એમએસ એસક્યુએલ ઑપ્ટિમાઇઝેશન ખોટું હોઈ શકે છે, જેમાં નીચેની શરતોનો સમાવેશ થાય છે:

1. જો ત્યાં પહેલાથી જ ક્ષેત્રોના સમાન સમૂહ સાથે અનુક્રમણિકાઓ છે
2. જો કોષ્ટકમાંના ક્ષેત્રોને ઇન્ડેક્સીંગ પ્રતિબંધોને કારણે અનુક્રમિત કરી શકાતા નથી (વધુ વિગતમાં વર્ણવેલ છે અહીં).

2) વિશેષતાઓને એક નવી વિશેષતામાં મર્જ કરવી

કેટલીકવાર એક કોષ્ટકમાંથી કેટલાક ક્ષેત્રો, જે શરતોના જૂથ માટે આધાર તરીકે સેવા આપે છે, તેને એક નવું ક્ષેત્ર રજૂ કરીને બદલી શકાય છે.

આ ખાસ કરીને સ્ટેટસ ફીલ્ડ્સ માટે સાચું છે, જે સામાન્ય રીતે બીટ અથવા પૂર્ણાંક પ્રકારમાં હોય છે.

ઉદાહરણ:

IsClosed = 0 અને રદ કરેલ = 0 અને સક્ષમ = 0 દ્વારા બદલવામાં આવે છે સ્થિતિ = 1.

આ તે સ્થાન છે જ્યાં આ સ્થિતિઓ કોષ્ટકમાં ભરેલી છે તેની ખાતરી કરવા માટે પૂર્ણાંક સ્થિતિ વિશેષતા રજૂ કરવામાં આવે છે. આગળ, આ નવી વિશેષતા અનુક્રમિત છે.

આ કામગીરીની સમસ્યાનો મૂળભૂત ઉકેલ છે, કારણ કે અમે બિનજરૂરી ગણતરીઓ વિના ડેટાને ઍક્સેસ કરીએ છીએ.

3) દૃશ્યનું ભૌતિકકરણ

કમનસીબે, માં LINQ પ્રશ્નો ટેમ્પરરી કોષ્ટકો, CTE અને ટેબલ વેરીએબલ્સનો સીધો ઉપયોગ કરી શકાતો નથી.

જો કે, આ કેસ માટે ઑપ્ટિમાઇઝ કરવાની બીજી રીત છે - અનુક્રમિત દૃશ્યો.

શરત જૂથ (ઉપરના ઉદાહરણમાંથી) IsClosed = 0 અને રદ કરેલ = 0 અને સક્ષમ = 0 (અથવા અન્ય સમાન શરતોનો સમૂહ) મોટા સમૂહમાંથી ડેટાના નાના ટુકડાને કેશ કરીને, અનુક્રમિત દૃશ્યમાં તેનો ઉપયોગ કરવાનો સારો વિકલ્પ બની જાય છે.

પરંતુ દૃશ્યને સાકાર કરતી વખતે સંખ્યાબંધ પ્રતિબંધો છે:

1. સબક્વેરીઝ, કલમોનો ઉપયોગ અસ્તિત્વમાં છે નો ઉપયોગ કરીને બદલવી જોઈએ જોડાઓ
2. તમે વાક્યોનો ઉપયોગ કરી શકતા નથી UNION, યુનિયન બધા, બાકાત, ઇન્ટરસેક્ટ
3. તમે કોષ્ટક સંકેતો અને કલમોનો ઉપયોગ કરી શકતા નથી વિકલ્પ
4. ચક્ર સાથે કામ કરવાની કોઈ શક્યતા નથી
5. વિવિધ કોષ્ટકોમાંથી એક દૃશ્યમાં ડેટા પ્રદર્શિત કરવું અશક્ય છે

તે યાદ રાખવું અગત્યનું છે કે અનુક્રમિત દૃશ્યનો ઉપયોગ કરવાનો વાસ્તવિક લાભ ફક્ત તેને ખરેખર અનુક્રમિત કરીને જ પ્રાપ્ત કરી શકાય છે.

પરંતુ જ્યારે કોઈ દૃશ્યને કૉલ કરવામાં આવે ત્યારે, આ અનુક્રમણિકાઓનો ઉપયોગ થઈ શકશે નહીં, અને તેનો સ્પષ્ટ ઉપયોગ કરવા માટે, તમારે સ્પષ્ટ કરવું આવશ્યક છે સાથે(NOEXPAND).

ત્યારથી LINQ પ્રશ્નો કોષ્ટક સંકેતોને વ્યાખ્યાયિત કરવું અશક્ય છે, તેથી તમારે બીજું પ્રતિનિધિત્વ બનાવવું પડશે - નીચેના ફોર્મનું "રૅપર":

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

4) કોષ્ટક કાર્યોનો ઉપયોગ કરવો

ઘણીવાર માં LINQ પ્રશ્નો સબક્વેરીઝના મોટા બ્લોક્સ અથવા જટિલ માળખા સાથેના દૃશ્યોનો ઉપયોગ કરીને બ્લોક્સ ખૂબ જ જટિલ અને સબઓપ્ટિમલ એક્ઝેક્યુશન સ્ટ્રક્ચર સાથે અંતિમ ક્વેરી બનાવે છે.

માં કોષ્ટક કાર્યોનો ઉપયોગ કરવાના મુખ્ય લાભો LINQ પ્રશ્નો:

1. ક્ષમતા, દૃશ્યોના કિસ્સામાં, ઑબ્જેક્ટ તરીકે ઉપયોગમાં લેવા અને ઉલ્લેખિત કરવાની, પરંતુ તમે ઇનપુટ પરિમાણોનો સમૂહ પસાર કરી શકો છો:
   ફંક્શનમાંથી (@param1, @param2 ...)
   પરિણામે, લવચીક ડેટા સેમ્પલિંગ પ્રાપ્ત કરી શકાય છે
2. ટેબલ ફંક્શનનો ઉપયોગ કરવાના કિસ્સામાં, ઉપર વર્ણવેલ અનુક્રમિત દૃશ્યોના કિસ્સામાં આવા કોઈ મજબૂત પ્રતિબંધો નથી:
   1. કોષ્ટક સંકેતો:
      દ્વારા LINQ તમે સ્પષ્ટ કરી શકતા નથી કે કયા અનુક્રમણિકાઓનો ઉપયોગ કરવો જોઈએ અને ક્વેરી કરતી વખતે ડેટા અલગતા સ્તર નક્કી કરી શકો છો.
      પરંતુ કાર્યમાં આ ક્ષમતાઓ છે.
      ફંક્શન સાથે, તમે એકદમ સતત એક્ઝેક્યુશન ક્વેરી પ્લાન હાંસલ કરી શકો છો, જ્યાં ઇન્ડેક્સ અને ડેટા આઇસોલેશન લેવલ સાથે કામ કરવાના નિયમો વ્યાખ્યાયિત કરવામાં આવ્યા છે.
   2. ફંક્શનનો ઉપયોગ અનુક્રમિત દૃશ્યોની તુલનામાં, મેળવવા માટે પરવાનગી આપે છે:
      • જટિલ ડેટા સેમ્પલિંગ તર્ક (લૂપ્સનો ઉપયોગ કરીને પણ)
      • ઘણાં વિવિધ કોષ્ટકોમાંથી ડેટા મેળવવું
      • ઉપયોગ UNION и અસ્તિત્વમાં છે

3. ઓફર વિકલ્પ જ્યારે આપણે સહવર્તી નિયંત્રણ પ્રદાન કરવાની જરૂર હોય ત્યારે ખૂબ જ ઉપયોગી વિકલ્પ(MAXDOP N), ક્વેરી એક્ઝેક્યુશન પ્લાનનો ક્રમ. દાખ્લા તરીકે:
   • તમે ક્વેરી પ્લાનની ફરજિયાત પુનઃનિર્માણનો ઉલ્લેખ કરી શકો છો વિકલ્પ (ફરી કમ્પાઇલ)
   • તમે સ્પષ્ટ કરી શકો છો કે ક્વેરી પ્લાનને ક્વેરીમાં ઉલ્લેખિત જોઇન ઓર્ડરનો ઉપયોગ કરવા માટે દબાણ કરવું કે કેમ વિકલ્પ (ફોર્સ ઓર્ડર)

   વિશે વધુ વિગતો વિકલ્પ વર્ણવેલ અહીં.

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] વ્યુ પર એક્ઝિક્યુટ કરવામાં આવે છે, જે [Email] = @p__linq__0 માટે અમને આઉટપુટ સિલેક્શનને મર્યાદિત કરવાની મંજૂરી આપવી જોઈએ. અસ્તિત્વમાં છે) સેંકડો રેકોર્ડ્સ સુધી.

અને એવું લાગે છે કે સબક્વેરીએ [ઈમેલ] = @p__linq__0 દ્વારા એકવાર રેકોર્ડની ગણતરી કરવી જોઈએ, અને પછી આ સો રેકોર્ડ્સના બે આઈડી દ્વારા પ્રશ્નો સાથે જોડાયેલા હોવા જોઈએ, અને ક્વેરી ઝડપી હશે.

વાસ્તવમાં, બધા કોષ્ટકોનું ક્રમિક જોડાણ છે: OperativeQuestions ના Id સાથે Id પ્રશ્નોના પત્રવ્યવહારને તપાસવું અને ઈમેલ દ્વારા ફિલ્ટર કરવું.

વાસ્તવમાં, વિનંતી તમામ હજારો OperativeQuestions રેકોર્ડ્સ સાથે કામ કરે છે, પરંતુ માત્ર ઈમેઈલ દ્વારા રસના ડેટાની જરૂર છે.

ઑપરેટિવ પ્રશ્નો ટેક્સ્ટ જુઓ:

વિનંતી નંબર 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();

આ ચોક્કસ કિસ્સામાં, અમે તૈયાર પરિણામો ("સક્રિય પ્રશ્નો") સાથે એક અલગ કોષ્ટક રજૂ કર્યા વિના, માળખાકીય ફેરફારો વિના આ સમસ્યાના ઉકેલ માટે વિચારણા કરી રહ્યા છીએ, જેમાં તેને ડેટા સાથે ભરવા અને તેને અદ્યતન રાખવા માટે એક પદ્ધતિની જરૂર પડશે. .

જો કે આ એક સારો ઉકેલ છે, આ સમસ્યાને ઑપ્ટિમાઇઝ કરવાનો બીજો વિકલ્પ છે.

મુખ્ય હેતુ OperativeQuestions વ્યુમાંથી [Email] = @p__linq__0 દ્વારા એન્ટ્રીઓ કેશ કરવાનો છે.

ડેટાબેઝમાં ટેબલ ફંક્શન [dbo].[OperativeQuestionsUserMail]નો પરિચય આપો.

ઇનપુટ પેરામીટર તરીકે ઈમેલ મોકલીને, અમે મૂલ્યોનું કોષ્ટક પાછું મેળવીએ છીએ:

વિનંતી નંબર 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. સરેરાશ અવરોધિત સમયને સ્વીકાર્ય મૂલ્યો સુધી ઘટાડવો

નિષ્કર્ષ

ડેટાબેઝ કોલ્સનું ઓપ્ટિમાઇઝેશન અને ફાઇન-ટ્યુનિંગ એમએસ એસક્યુએલ દ્વારા LINQ એક સમસ્યા છે જે ઉકેલી શકાય છે.

આ કાર્યમાં સચેતતા અને સાતત્ય ખૂબ જ મહત્વપૂર્ણ છે.

પ્રક્રિયાની શરૂઆતમાં:

1. તે ડેટા તપાસવો જરૂરી છે કે જેની સાથે વિનંતી કાર્ય કરે છે (મૂલ્યો, પસંદ કરેલા ડેટા પ્રકારો)
2. આ ડેટાનું યોગ્ય ઇન્ડેક્સીંગ કરો
3. કોષ્ટકો વચ્ચે જોડાવાની સ્થિતિની શુદ્ધતા તપાસો

આગામી ઓપ્ટિમાઇઝેશન પુનરાવૃત્તિ દર્શાવે છે:

1. વિનંતીના આધારે અને મુખ્ય વિનંતી ફિલ્ટરને વ્યાખ્યાયિત કરે છે
2. સમાન ક્વેરી બ્લોક્સનું પુનરાવર્તન અને શરતોના આંતરછેદનું વિશ્લેષણ
3. માટે SSMS અથવા અન્ય GUI માં SQL સર્વર પોતાને શ્રેષ્ઠ બનાવે છે SQL ક્વેરી (એક મધ્યવર્તી ડેટા સ્ટોરેજની ફાળવણી, આ સ્ટોરેજનો ઉપયોગ કરીને પરિણામી ક્વેરી બનાવવી (ત્યાં ઘણા હોઈ શકે છે))
4. છેલ્લા તબક્કે, પરિણામને આધારે લેવું SQL ક્વેરી, માળખું ફરીથી બનાવવામાં આવી રહ્યું છે LINQ ક્વેરી

પરિણામી LINQ ક્વેરી ઓળખાયેલ શ્રેષ્ઠ માટે બંધારણમાં સમાન બનવું જોઈએ SQL ક્વેરી બિંદુ 3 થી.

સ્વીકૃતિઓ

સહકાર્યકરોનો ખૂબ ખૂબ આભાર jobgemws и alex_ozr કંપની તરફથી ફોર્ટિસ આ સામગ્રી તૈયાર કરવામાં મદદ માટે.

સોર્સ: www.habr.com