አንድ ገንቢ ለዲቢኤው ወይም ለቢዝነስ ባለቤቱ የሚያመጣው የተለመደ ጥያቄ ለPostgreSQL አማካሪ የሚያመጣው ሁልጊዜ ማለት ይቻላል ተመሳሳይ ነው፡ "ጥያቄዎች በመረጃ ቋቱ ላይ ለመጠናቀቅ ለምን ያህል ጊዜ የሚወስዱት ለምንድን ነው?"
ባህላዊ ምክንያቶች ስብስብ;
- ውጤታማ ያልሆነ ስልተ ቀመር
በአስር ሺዎች በሚቆጠሩ መዝገቦች ላይ ብዙ CTEዎችን ለመቀላቀል ስትወስኑ - ጊዜ ያለፈበት ስታቲስቲክስ
በሠንጠረዡ ውስጥ ያለው ትክክለኛው የመረጃ ስርጭት ባለፈው ጊዜ ANALYZE ከተሰበሰበው በጣም የተለየ ከሆነ - በንብረቶች ውስጥ "መሰካት".
እና የሲፒዩ በቂ የሆነ የኮምፒዩተር ሃይል የለም፣ ጊጋባይት የማህደረ ትውስታ በየጊዜው እየተነፈሰ ነው፣ ወይም ዲስኩ ሁሉንም የመረጃ ቋቱን “ፍላጎቶች” መጠበቅ አይችልም። - ማገድ ከተወዳዳሪ ሂደቶች
እና እገዳዎች ለመያዝ እና ለመተንተን በጣም ከባድ ከሆኑ እኛ ለሌላው ሁሉ ያስፈልገናል የመጠይቅ እቅድበመጠቀም ሊገኝ የሚችል
ግን በተመሳሳይ ሰነድ ላይ እንደተገለጸው
"እቅድን መረዳት ጥበብ ነው፣ እና እሱን ለመቆጣጠር የተወሰነ ልምድ ይጠይቃል..."
ግን ትክክለኛውን መሳሪያ ከተጠቀሙ ያለሱ ማድረግ ይችላሉ!
የመጠይቅ እቅድ በተለምዶ ምን ይመስላል? እንደ 'ዛ ያለ ነገር:
Index Scan using pg_class_relname_nsp_index on pg_class (actual time=0.049..0.050 rows=1 loops=1)
Index Cond: (relname = $1)
Filter: (oid = $0)
Buffers: shared hit=4
InitPlan 1 (returns $0,$1)
-> Limit (actual time=0.019..0.020 rows=1 loops=1)
Buffers: shared hit=1
-> Seq Scan on pg_class pg_class_1 (actual time=0.015..0.015 rows=1 loops=1)
Filter: (relkind = 'r'::"char")
Rows Removed by Filter: 5
Buffers: shared hit=1
ወይም እንደዚህ:
"Append (cost=868.60..878.95 rows=2 width=233) (actual time=0.024..0.144 rows=2 loops=1)"
" Buffers: shared hit=3"
" CTE cl"
" -> Seq Scan on pg_class (cost=0.00..868.60 rows=9972 width=537) (actual time=0.016..0.042 rows=101 loops=1)"
" Buffers: shared hit=3"
" -> Limit (cost=0.00..0.10 rows=1 width=233) (actual time=0.023..0.024 rows=1 loops=1)"
" Buffers: shared hit=1"
" -> CTE Scan on cl (cost=0.00..997.20 rows=9972 width=233) (actual time=0.021..0.021 rows=1 loops=1)"
" Buffers: shared hit=1"
" -> Limit (cost=10.00..10.10 rows=1 width=233) (actual time=0.117..0.118 rows=1 loops=1)"
" Buffers: shared hit=2"
" -> CTE Scan on cl cl_1 (cost=0.00..997.20 rows=9972 width=233) (actual time=0.001..0.104 rows=101 loops=1)"
" Buffers: shared hit=2"
"Planning Time: 0.634 ms"
"Execution Time: 0.248 ms"
ግን እቅዱን “ከሉህ” ጽሑፍ ውስጥ ማንበብ በጣም ከባድ እና ግልጽ ያልሆነ ነው-
- በመስቀለኛ መንገድ ውስጥ ይታያል በንዑስ ዛፍ ሀብቶች ድምር
ማለትም አንድን የተወሰነ መስቀለኛ መንገድ ለማስኬድ ምን ያህል ጊዜ እንደወሰደ ወይም ይህ ከጠረጴዛው ላይ ምን ያህል በትክክል ማንበብ ከዲስክ ላይ መረጃ እንዳመጣ ለመረዳት ፣ አንዱን ከሌላው መቀነስ ያስፈልግዎታል። - የመስቀለኛ መንገድ ጊዜ ያስፈልጋል በ loops ማባዛት
አዎ ፣ መቀነስ “በጭንቅላቱ ውስጥ” መከናወን ያለበት በጣም የተወሳሰበ ቀዶ ጥገና አይደለም - ከሁሉም በላይ ፣ የማስፈጸሚያ ጊዜ ለአንድ መስቀለኛ መንገድ አፈፃፀም በአማካይ ይገለጻል ፣ እና በመቶዎች የሚቆጠሩ ሊኖሩ ይችላሉ። - ደህና, እና ይህ ሁሉ አንድ ላይ ዋናውን ጥያቄ እንድንመልስ ያግዶናል - ስለዚህ ማን "በጣም ደካማው አገናኝ"?
ይህንን ሁሉ በመቶዎች ለሚቆጠሩ ገንቢዎቻችን ለማስረዳት ስንሞክር ከውጪ እንዲህ ያለ ነገር እንደሚመስል ተገነዘብን።
እና እኛ ያስፈልገናል ማለት ነው ...
መሣሪያ
በውስጡም እንደ ዕቅዱ እና ጥያቄው "ጥፋተኛው ማን እና ምን ማድረግ እንዳለበት" ለመረዳት የሚረዱትን ሁሉንም ቁልፍ መካኒኮች ለመሰብሰብ ሞክረን ነበር. ደህና፣ እና የልምድህን የተወሰነ ክፍል ከማህበረሰቡ ጋር አካፍል።
ይገናኙ እና ይጠቀሙ -
የእቅዶች ታይነት
ይህን በሚመስልበት ጊዜ እቅዱን ለመረዳት ቀላል ነው?
Seq Scan on pg_class (actual time=0.009..1.304 rows=6609 loops=1)
Buffers: shared hit=263
Planning Time: 0.108 ms
Execution Time: 1.800 ms
በእውነቱ አይደለም ፡፡
ግን እንደዚህ ፣ በአህጽሮት መልክቁልፍ አመልካቾች ሲለያዩ የበለጠ ግልጽ ነው፡-
ነገር ግን እቅዱ የበለጠ የተወሳሰበ ከሆነ ወደ ማዳን ይመጣል pichart ጊዜ ስርጭት በመስቀለኛ መንገድ፡
ደህና, በጣም አስቸጋሪ ለሆኑ አማራጮች እሱ ለመርዳት ቸኩሎ ነው የሂደት ሰንጠረዥ:
ለምሳሌ፣ አንድ እቅድ ከአንድ በላይ ትክክለኛ ስር ሲኖረው በጣም ቀላል ያልሆኑ ሁኔታዎች አሉ።
መዋቅራዊ ፍንጮች
ደህና, የእቅዱ አጠቃላይ መዋቅር እና የታመሙ ቦታዎች ቀድሞውኑ ተዘርግተው የሚታዩ ከሆነ ለምን ለገንቢው አጉልተው በ "ሩሲያኛ ቋንቋ" ለምን አታብራሩዋቸውም?
አስቀድመን ሁለት ደርዘን የሚሆኑ እንደዚህ ያሉ የምክር አብነቶችን ሰብስበናል።
የመስመር-በ-መስመር መጠይቅ መገለጫ
አሁን፣ ዋናውን መጠይቅ በተተነተነው እቅድ ላይ ከጫኑት፣ በእያንዳንዱ ግለሰብ መግለጫ ላይ ምን ያህል ጊዜ እንዳጠፋ ማየት ትችላለህ - እንደዚህ ያለ ነገር፡-
... ወይም እንደዚህ እንኳን:
መለኪያዎችን ወደ ጥያቄ በመተካት።
በእቅዱ ላይ ጥያቄን ብቻ ሳይሆን ግቤቶችን ከመዝገቡ ዝርዝር መስመር ላይ “ከያያዙት” በተጨማሪ ከአማራጮች ውስጥ በአንዱ መቅዳት ይችላሉ-
- በጥያቄው ውስጥ ከዋጋ ምትክ ጋር
በመሠረትዎ ላይ ቀጥተኛ አፈፃፀም እና ተጨማሪ መገለጫSELECT 'const', 'param'::text;
- በPREPARE/EXECUTE በኩል የእሴት ምትክ
የጊዜ ሰሌዳውን ሥራ ለመኮረጅ, የፓራሜትሪክ ክፍሉ ችላ ሊባል በሚችልበት ጊዜ - ለምሳሌ, በተከፋፈሉ ጠረጴዛዎች ላይ ሲሰሩ.DEALLOCATE ALL; PREPARE q(text) AS SELECT 'const', $1::text; EXECUTE q('param'::text);
የእቅዶች መዝገብ ቤት
ይለጥፉ ፣ ይተንትኑ ፣ ከባልደረባዎች ጋር ያካፍሉ! እቅዶቹ በማህደሩ ውስጥ ይቀራሉ፣ እና በኋላ ወደ እነርሱ መመለስ ይችላሉ፦
ነገር ግን ሌሎች ዕቅዶችዎን እንዲያዩት ካልፈለጉ፣ “በማህደር ውስጥ አታትሙ” የሚለውን ሳጥን ላይ ምልክት ማድረግን አይርሱ።
በሚቀጥሉት ጽሁፎች ውስጥ እቅድ ሲተነተን ስለሚነሱ ችግሮች እና ውሳኔዎች እናገራለሁ.
ምንጭ: hab.com