MySQL EXPLAIN ANALYZE පැහැදිලි කිරීම: ක්‍රියාත්මක සැලසුම් කියවීම සහ විමසුම් සවිස්තර කිරීම (8.0 මාර්ගෝපදේශය)

1. හැඳින්වීම

ක්‍රියාත්මක සැලසුම්: දත්ත ගබඩා කාර්ය සාධන අභිලක්ෂණ සඳහා අත්‍යවශ්‍ය

වෙබ් යෙදුම් සහ ව්‍යාපාර පද්ධතිවල, දත්ත ගබඩා කාර්ය සාධනය යනු සමස්ත ප්‍රතිචාර කාලයට සෘජුවම බලපාන වැදගත් සාධකයකි. විශේෂයෙන් MySQL භාවිතා කරන විට, “ක්‍රියාත්මක සැලසුම” පිළිබඳ අවබෝධය ප්‍රශ්න කාර්යක්ෂමතාවය ඇගයීමට අත්‍යවශ්‍ය වේ. සාම්ප්‍රදායික EXPLAIN විධානය SQL ප්‍රකාශයක් ක්‍රියාත්මක කිරීමට පෙර ක්‍රියාත්මක සැලසුම පෙන්වයි සහ දිගු කාලයක් තිස්සේ සංවර්ධකයන්ට වටිනා අවබෝධ ලබා දී ඇත.

MySQL 8.0 හි “EXPLAIN ANALYZE” හඳුන්වා දී ඇත

MySQL 8.0.18 හි හඳුන්වා දී ඇති EXPLAIN ANALYZE යනු සාම්ප්‍රදායික EXPLAIN හි ශක්තිමත් වර්ධනයකි. EXPLAIN එකක් “තත්ත්ව සැලසුම” පමණක් ලබා දුන් අතර, EXPLAIN ANALYZE වස්තුත්‍රය ක්‍රියාත්මක කර ප්‍රශ්න කාලය සහ සැකසූ පේළි ගණන වැනි මානකළ දත්ත ආපසු ලබා දෙයි. මෙය බොත්තනැගීම් හඳුනා ගැනීමට සහ ප්‍රශ්න අභිලක්ෂණ ප්‍රතිඵල වල සත්‍යතාවය තහවුරු කිරීමට වඩා නිවැරදි කරයි.

EXPLAIN ANALYZE වැදගත් වන්නේ ඇයි

උදාහරණයක් ලෙස, JOIN ක්‍රමය, දර්ශක භාවිතය, සහ පෙරහන් කොන්දේසි ක්‍රියාත්මක කාලයට වැදගත් බලපෑම් කරයි. EXPLAIN ANALYZE භාවිතා කිරීමෙන්, ඔබට SQL ප්‍රකාශයක් කෙසේ ක්‍රියා කරයි යන්න දෘශ්‍යමය ලෙස තහවුරු කර, අකාර්යක්ෂමතා ඇති ස්ථාන සහ කුමන දේ අභිලක්ෂණය කළ යුතුද යන්න තීරණය කළ හැක. විශාල දත්ත කට්ටල හෝ සංකීර්ණ ප්‍රශ්න සමඟ වැඩ කරන විට මෙය විශේෂයෙන් අත්‍යවශ්‍ය වේ.

මෙම ලිපියේ අරමුණ සහ ඉලක්ක ප්‍රේක්ෂකයන්

මෙම ලිපිය MySQL හි EXPLAIN ANALYZE මූලික කරුණු සිට එහි ප්‍රතිඵල විග්‍රහ කිරීම සහ ප්‍රායෝගික අභිලක්ෂණ තාක්ෂණයන් යෙදවීම දක්වා සියල්ල පැහැදිලි කරයි. එය MySQL නිතර භාවිතා කරන සංවර්ධකයන් සහ පාරිසරික ඉංජිනේරුවන් සඳහා, කාර්ය සාධන සැකසීමේ රුචිය ඇති ඉංජිනේරුවන් සඳහා අරමුණු කර ඇත. ආරම්භකයන්ටත් පැහැදිලි කිරීම සඳහා, අපි පදවි විස්තර සහ ප්‍රායෝගික උදාහරණ ඇතුළත් කර ඇත.

2. EXPLAIN සහ EXPLAIN ANALYZE අතර වෙනස්කම්

EXPLAIN හි භූමිකාව සහ මූලික භාවිතය

MySQL හි EXPLAIN යනු SQL ප්‍රකාශයක් (විශේෂයෙන් SELECT ප්‍රකාශයක්) කෙසේ ක්‍රියාත්මක වනු ඇතිද යන්න පෙර අවබෝධ කර ගැනීමට භාවිතා කරන විශ්ලේෂණ මෙවලමකි. එය දර්ශක භාවිතය, join ක්‍රමය, සහ සෙවුම් පරාස වැනි ක්‍රියාත්මක සැලසුම් තහවුරු කිරීමට ඉඩ සලසයි.

උදාහරණයක්:

EXPLAIN SELECT * FROM users WHERE age > 30;

මෙම විධානය ක්‍රියාත්මක කරන විට, MySQL ප්‍රශ්නය සැබෑවටම ක්‍රියාත්මක නොකරයි, එයට පරිවර්තනය කරගැනීමට සැලසුම් කරන ආකාරය වගුවක් ලෙස පෙන්වයි. ප්‍රතිඵලය භාවිතා කරන දර්ශකය (key), ප්‍රවේශ ක්‍රමය (type), සහ අනුමාන පේළි ගණන (rows) වැනි තොරතුරු ඇතුළත් වේ.

EXPLAIN ANALYZE හි භූමිකාව සහ විශේෂාංග

එයට විරුද්ධව, MySQL 8.0.18 හි හඳුන්වා දී ඇති EXPLAIN ANALYZE ප්‍රශ්නය ක්‍රියාත්මක කර සැබෑ මැනුම් අගයන් මත පදනම්ව ක්‍රියාත්මක සැලසුම පෙන්වයි. මෙය සාම්ප්‍රදායික EXPLAIN හි නොපෙනී තිබූ විස්තර, උදාහරණ ලෙස සැබෑ සැකසීමේ කාලය සහ සැබෑවටම සැකසූ පේළි ගණන, තහවුරු කිරීමට හැකියාව ලබා දෙයි.

උදාහරණය:

EXPLAIN ANALYZE SELECT * FROM users WHERE age > 30;

මෙම විධානය ප්‍රශ්නය ක්‍රියාත්මක කර පහත සඳහන් දෑ ඇතුළත් ප්‍රතිඵලය ලබා දෙයි:

• සැලසුමේ සෑම පියවරක් සඳහා ක්‍රියාත්මක කාලය (උදා. 0.0022 sec )
• ආසන්නව කියවූ පේළි ගණන (rows)
• සැකසීමේ ව්‍යුහය (TREE ආකාරය භාවිතා කර පහසුවෙන් දෘශ්‍යමාන කළ හැක)

ප්‍රධාන වෙනස්කම් සාරාංශය

ඔබට කුමන එක භාවිතා කළ යුතුද?

• EXPLAIN භාවිතා කරන්න ඔබට ප්‍රශ්න ව්‍යුහය ඉක්මනින් පරීක්ෂා කිරීමට අවශ්‍ය නම්.
• EXPLAIN ANALYZE භාවිතා කරන්න ඔබට ක්‍රියාත්මක කාලය සහ ප්‍රශ්න වියදම පිළිබඳ නිරවද්‍ය විස්තර අවශ්‍ය නම්.

කාර්ය සාධන සැකසීමේ අවස්ථා වල, EXPLAIN ANALYze අනුමානවලට පරීක්ෂා නොකර සැබෑ ක්‍රියාත්මක දත්ත මත පදනම්ව අභිලක්ෂණය කිරීමට ඉඩ සලසයි, එය ඉතා ශක්තිමත් මෙවලමක් බවට පත්වේ.

3. EXPLAIN ANALYZE හි ප්‍රතිඵල ආකාර

තුන් ප්‍රතිඵල ආකාර: සාම්ප්‍රදායික, JSON, සහ TREE

MySQL හි EXPLAIN ANALYZE ඔබේ අරමුණ අනුව විවිධ ආකාර වල ප්‍රතිඵල ලබා දිය හැක. MySQL 8.0 සහ ඊට පසු, පහත සඳහන් තුන් ආකාර ලබා ගත හැක.

වෙනස්කම් ගැන වැඩි විස්තරයක් බලමු.

සාම්ප්‍රදායික ආකාරය (පෙරනිමි)

TRADITIONAL output යනු සාම්ප්‍රදායික EXPLAIN රීතියට සමාන වන අතර ඔබට ක්‍රියාත්මක සැලසුම් පරීක්ෂා කිරීමට හුරුපුරුදු ආකාරයකින් ඉඩ සලසයි. ඔබ EXPLAIN ANALYZE ක්‍රියාත්මක කර, ආකෘතියක් නිරූපණය නොකළහොත්, ප්‍රතිඵලය සාමාන්‍යයෙන් මෙම ආකෘතියෙන් පෙන්වයි.

උදාහරණ ප්‍රතිඵල (උපුටා ගැනීම):

-> Filter: (age > 30)  (cost=0.35 rows=10) (actual time=0.002..0.004 rows=8 loops=1)

• cost : අනුමානිත පිරිවැය
• actual time : මැනුම් කළ කාලය
• rows : සැකසූ පේළි ගණනේ අනුමාන (ක්‍රියාත්මක කිරීමට පෙර)
• loops : ලූප් ගණන (JOIN සඳහා විශේෂයෙන් වැදගත්)

TRADITIONAL ආකෘතිය මනුෂ්‍යයන්ට පරීක්ෂා කර තේරුම් ගැනීමට පහසු වන අතර, ආරම්භකයන්ට සහ ඉක්මන් පරීක්ෂණ සඳහා සුදුසු කරයි.

JSON Format

JSON ආකෘතිය වැඩි විස්තර සහිත වන අතර, වැඩසටහන් මට්ටමින් හසුරවීමට පහසුය. ප්‍රතිඵලය ව්‍යුහගත වන අතර, සෑම නෝඩ් එකක්ම අන්තර්ගත වස්තුවක් ලෙස නිරූපණය වේ.

විධානය:

EXPLAIN ANALYZE FORMAT=JSON SELECT * FROM users WHERE age > 30;

ප්‍රතිඵලයේ කොටසක් (අලංකාර මුද්‍රණය):

{
  "query_block": {
    "table": {
      "table_name": "users",
      "access_type": "range",
      "rows_examined_per_scan": 100,
      "actual_rows": 80,
      "filtered": 100,
      "cost_info": {
        "query_cost": "0.35"
      },
      "timing": {
        "start_time": 0.001,
        "end_time": 0.004
      }
    }
  }
}

මෙම ආකෘතිය දෘශ්‍යමයව අඩු පඬුවක් ඇති නමුත්, දත්ත විග්‍රහ මෙවලම් හෝ පුවරුවලට ආදානය කිරීමට ඔබට අවශ්‍ය වන විට ඉතා පහසුය.

TREE Format (Readable and Great for Visualizing Structure)

TREE ආකෘතිය විමසුම් ක්‍රියාත්මක ව්‍යුහය ගසක් ලෙස පෙන්වයි, එය JOIN සහ උපවිමසුම් සැකසීමේ අනුපිළිවෙළ තේරුම් ගැනීමට පහසු කරයි.

විධානය:

EXPLAIN ANALYZE FORMAT=TREE SELECT * FROM users WHERE age > 30;

උදාහරණ ප්‍රතිඵල (සරල කළ):

-> Table scan on users  (actual time=0.002..0.004 rows=8 loops=1)

සංකීර්ණ විමසුම් සඳහා, අන්තර්ගතය මෙසේ පෙනේ:

-> Nested loop join
    -> Table scan on users
    -> Index lookup on orders using idx_user_id

TREE ආකෘතිය විශේෂයෙන් බොහෝ JOIN හෝ සංකීර්ණ අන්තර්ගතය ඇති විමසුම් සඳහා ප්‍රයෝජනවත් වන අතර, ඔබට සැකසීමේ ප්‍රවාහය අත්පත් කර ගැනීමට අවශ්‍ය වේ.

Which Format Should You Use?

ඔබේ ඉලක්කයට හොඳින් ගැළපෙන ආකෘතිය තෝරා, ක්‍රියාත්මක සැලසුම අතින් පඬුවක් සහ විශ්ලේෂණාත්මක රීතියෙන් පරීක්ෂා කරන්න.

4. How to Interpret Execution Plans

Why You Need to Read Execution Plans

MySQL විමසුම් කාර්ය සාධනය දත්ත ප්‍රමාණය සහ දර්ශක (index) ලබාගත හැකියාව මත බොහෝ විට වෙනස් වේ. EXPLAIN ANALYZE හි ක්‍රියාත්මක සැලසුම් ප්‍රතිඵලය නිවැරදිව විශ්ලේෂණය කිරීමෙන්, ඔබට කාර්යය කුමන තැනක අතුරුදන් වෙමින් පවතිනද, කුමන දේ සංශෝධනය කළ යුතුද යන්න වස්තුමයව හඳුනාගත හැක. මෙම කුසලතාව කාර්ය සාධන සැකසීමේ මූලික කොටසක් වන අතර, විශාල දත්ත කට්ටල හෝ සංකීර්ණ JOIN ගැලපෙන විමසුම් සඳහා විශේෂයෙන් වැදගත් වේ.

Basic Structure of an Execution Plan

EXPLAIN ANALYZE හි ප්‍රතිඵලය පහත සඳහන් තොරතුරු ඇතුළත් කරයි (මෙහි TRADITIONAL-ශෛලිය ආකෘතිය මත පදනම්ව විස්තර කර ඇත):

-> Filter: (age > 30)  (cost=0.35 rows=10) (actual time=0.002..0.004 rows=8 loops=1)

මෙම එකම පේළිය බහු වැදගත් ක්ෂේත්‍ර අඩංගු වේ.

How to Read Key Fields

1. cost vs. actual time

• cost යනු MySQL විසින් ගණනය කරන අභ්‍යන්තර අනුමානයක් වන අතර, සාපේක්ෂ ඇගයීම සඳහා භාවිතා වේ.
• actual time යනු සැබෑ ගත වූ කාලය පෙන්වයි, සහ කාර්ය සාධන විශ්ලේෂණයට වැඩි වැදගත්කමක් ඇත.

උදාහරණයක්:

(cost=0.35 rows=100) (actual time=0.002..0.004 rows=100)

අනුමාන සහ මැනුම් අතිශය සමීප නම්, ක්‍රියාත්මක සැලසුම සත්‍ය බවක් ඇති බවක් පෙනේ. පරතරය විශාල නම්, වගු සංඛ්‍යාලේඛන අසත්‍ය විය හැක.

2. rows vs. actual rows

• rows යනු MySQL පුරෝකථනය කරන පේළි ගණනයි.
• actual rows යනු සැබෑවට කියවූ පේළි ගණන (TRADITIONAL-ශෛලිය ආකෘතියේ වටකුරු තුළ ඇතුළත් වේ).

විශාල අසමතුලිතයක් පවතී නම්, ඔබට සංඛ්‍යාලේඛන නවීකරණය කිරීම හෝ දර්ශක (index) සැලැස්ම නැවත සලකා බැලීම අවශ්‍ය විය හැක.

3. loops

If loops=1, the step runs once. With JOINs or subqueries, you may see loops=10 or loops=1000. The larger the value, the more likely nested loops are causing heavy processing.

ක්‍රියාත්මක සැලසුම් (Execution Plans) හි අන්තර්ගත ව්‍යුහය තේරුම් ගන්න

When multiple tables are joined, the execution plan is shown as a tree (especially clear in TREE format).

Example:

-> Nested loop join
    -> Table scan on users
    -> Table scan on orders

ගැටලුව

• Both tables are fully scanned, resulting in a high join cost.

ප්‍රතිකාර

• Add an index on users.age and filter earlier to reduce the join workload.

කාර්ය සාධන බාධක (Performance Bottlenecks) හඳුනා ගැනීමේ ක්‍රම

Focusing on the following points makes bottlenecks easier to find:

• දිගු සැබෑ කාලය සහ බොහෝ පේළි ඇති නෝඩ්ස් : These consume most of the execution time
• සම්පූර්ණ වගු පරික්ෂණය සිදුවන ස්ථාන : Likely missing or unused indexes
• බොහෝ ලූප (loops) ඇති පියවර : Indicates inefficient JOIN order or nesting
• පේළි සහ සැබෑ පේළි අතර විශාල පරතර : Suggests inaccurate statistics or excessive data access

Use these insights as the foundation for the “Query Optimization” techniques introduced in the next section.

5. ප්‍රායෝගික විමසුම් අභිප්‍රේරණ උදාහරණ

විමසුම් අභිප්‍රේරණය (Query Optimization) යනු කුමක්ද?

Query optimization refers to reviewing and improving SQL statements so they can be executed more efficiently. Based on how MySQL processes queries internally (execution plans), you apply improvements such as adding indexes, adjusting join order, and eliminating unnecessary processing.

Here, we demonstrate how to improve queries using EXPLAIN ANALYZE with concrete examples.

උදාහරණය 1: ඉන්ඩෙක්ස් භාවිතයෙන් වේග වැඩි කිරීම

අභිප්‍රේරණයට පෙර

SELECT * FROM users WHERE email = 'example@example.com';

ක්‍රියාත්මක සැලසුම (උපුටා ගැනීම)

-> Table scan on users  (cost=10.5 rows=100000) (actual time=0.001..0.230 rows=1 loops=1)

ගැටලුව

• The output shows Table scan , meaning a full table scan is performed. With large datasets, this leads to significant delays.

විසඳුම: ඉන්ඩෙක්ස් එකතු කිරීම

CREATE INDEX idx_email ON users(email);

අභිප්‍රේරණය පසු ක්‍රියාත්මක සැලසුම

-> Index lookup on users using idx_email  (cost=0.1 rows=1) (actual time=0.001..0.002 rows=1 loops=1)

ප්‍රතිඵලය

• Execution time significantly reduced.
• Full table scan avoided by using the index.

උදාහරණය 2: සම්බන්ධන (Join) ක්‍රමලේඛය අභිප්‍රේරණය

අභිප්‍රේරණයට පෙර

SELECT * FROM orders
JOIN users ON orders.user_id = users.id
WHERE users.age > 30;

ක්‍රියාත්මක සැලසුම (උපුටා ගැනීම)

-> Nested loop join
    -> Table scan on orders
    -> Table scan on users

ගැටලුව

• Both tables are fully scanned, resulting in high join costs.

විසඳුම

• Add an index on users.age and filter first to reduce the join target size.

  CREATE INDEX idx_age ON users(age);
  

අභිප්‍රේරණය පසු ක්‍රියාත්මක සැලසුම

-> Nested loop join
    -> Index range scan on users using idx_age
    -> Index lookup on orders using idx_user_id

ප්‍රතිඵලය

• JOIN targets are filtered first, reducing overall processing load.

උදාහරණය 3: උපවිමසුම (Subquery) සංශෝධනය

අභිප්‍රේරණයට පෙර

SELECT * FROM users WHERE id IN (SELECT user_id FROM orders WHERE total > 1000);

ගැටලුව

• The subquery may be evaluated repeatedly, degrading performance.

විසඳුම: JOIN ලෙස නැවත ලියන්න

SELECT DISTINCT users.*
FROM users
JOIN orders ON users.id = orders.user_id
WHERE orders.total > 1000;

ප්‍රතිඵලය

• The execution plan is optimized for JOIN processing, and indexes are more likely to be used.

අභිප්‍රේරණයට පෙර/පසු සංසන්දනයේ වැදගත්කම

Using EXPLAIN ANALYZE, you can verify optimization results with actual measured values. By comparing execution time and row counts before and after improvements, you ensure that tuning efforts are based on real performance gains rather than assumptions.

අනුකූල කිරීමේ වැදගත් සැලකිලි

• බොහෝ ඉන්ඩෙක්ස් එකතු කිරීම ප්‍රතිඵලදායක නොවිය හැක (INSERT/UPDATE කාර්ය සාධනය මන්දගාමී වේ).
• ක්‍රියාත්මක සැලසුම් දත්ත ප්‍රමාණය සහ සංඛ්‍යාලේඛන මත පදනම් වේ, එබැවින් පරිසරය අනුව සත්‍යාපනය අවශ්‍ය වේ.
• එක් අනුකූල කිරීමක් සියල්ල විසඳන්නේ නැත. බොත්තලන විශ්ලේෂණය පළමුව සිදු කළ යුතුය.

6. අවධානම් සහ හොඳ පුරුදු

EXPLAIN ANALYZE භාවිතා කරන විට වැදගත් සටහන්

EXPLAIN ANALYZE ඉතා බලවත් වුවද, අනිසි භාවිතය වැරදි අවබෝධයන් හෝ මෙහෙයුම් අවදානම් ඇති කරවිය හැක. පහත කරුණු මත අවධානය යොමු කිරීමෙන්, ආරක්ෂිත සහ ප්‍රභාවී විමසුම් විශ්ලේෂණය සලස්විය හැක.

1. ඉදිරිපත් කිරීමේදී අවධානයෙන් නොදැක්කා ධාවනය කිරීමෙන් වැළකී සිටින්න

EXPLAIN ANALYZE ඇත්තෙන්ම විමසුම ක්‍රියාත්මක කරයි, වෙනස් කිරීමේ ප්‍රකාශ (INSERT/UPDATE/DELETE) සමඟ වැරදි ලෙස භාවිතා කිරීමෙන් දත්ත වෙනස් විය හැක.

• සාමාන්‍යයෙන්, එය SELECT ප්‍රකාශ සමඟ පමණක් භාවිතා කරන්න.
• ඉදිරිපත් කිරීමේ පරිසරයට වඩා පරික්ෂණ හෝ පරික්ෂා පරිසරයක ධාවනය කිරීම ප්‍රාථමික වේ.

2. කැෂ් කිරීමේ බලපෑම සලකා බලන්න

එකම විමසුම නැවත නැවත ක්‍රියාත්මක කරන විට MySQL කැෂ් එකෙන් ප්‍රතිඵල ලබා දිය හැක. එම නිසා, EXPLAIN ANALYZE වාර්තා කරන ක්‍රියාත්මක කාලය වාස්තුක ලෝකයේ හැසිරීමෙන් වෙනස් විය හැක.

ප්‍රතිකාර:

• ක්‍රියාත්මක කිරීමට පෙර කැෂ් එක පිරිසිදු කරන්න ( RESET QUERY CACHE; ).
• බහු වාරයක් ධාවනය කර සාමාන්‍ය අගයන් මත ඇගයීම කරන්න.

3. සංඛ්‍යාලේඛන නවීකරණය කර තබා ගන්න

MySQL වගුව සහ ඉන්ඩෙක්ස් සංඛ්‍යාලේඛන මත පදනම්ව ක්‍රියාත්මක සැලසුම් ගොඩනඟයි. සංඛ්‍යාලේඛන පරණ නම්, EXPLAIN සහ EXPLAIN ANALYZE දෙකම වැරදි තොරතුරු ලබා දිය හැක.

විශාල INSERT හෝ DELETE මෙහෙයුම් පසු, ANALYZE TABLE භාවිතා කර සංඛ්‍යාලේඛන නවීකරණය කරන්න.

ANALYZE TABLE users;

4. ඉන්ඩෙක්ස් එකක් සියලු ගැටළු විසඳන්නේ නැත

ඉන්ඩෙක්ස් බොහෝ විට කාර්ය සාධනය වැඩි කරයි, බොහෝ ඉන්ඩෙක්ස් ලිවීමේ මෙහෙයුම් මන්දගාමී කරයි.

සංයුක්ත ඉන්ඩෙක්ස් සහ තනි තීරුවේ ඉන්ඩෙක්ස් අතර තේරීමද වැදගත් වේ. විමසුම් රටාවන් සහ භාවිතා අනුපාතය මත පදනම්ව ඉන්ඩෙක්ස් සැලසුම් කරගන්න.

5. ක්‍රියාත්මක කාලය පමණක් මත තීරණය නොකරන්න

EXPLAIN ANALYZE හි ප්‍රතිඵල එකම විමසුමේ කාර්ය සාධනය පමණක් පෙන්වයි. සැබෑ යෙදුම් වල, ජාල ප්‍රමාදය හෝ පසුබැසීමේ සැකසුම් වාස්තුක බොත්තලන විය හැක.

ඒ නිසා, සම්පූර්ණ පද්ධති වාස්තුක සැලැස්ම තුළ විමසුම් විශ්ලේෂණය කරන්න.

හොඳ පුරුදු සාරාංශය

7. නිතර අසන ප්‍රශ්න (FAQ)

Q1. EXPLAIN ANALYZE කුමන අනුවාදයෙන් පලවී ඇත?

A.
MySQL හි EXPLAIN ANALYZE අනුවාද 8.0.18 සහ ඉදිරිපස දී හඳුන්වා දී ඇත. 8.0 ට පෙර අනුවාද වල එය සහය නොදේ, එබැවින් භාවිතා කිරීමට පෙර ඔබේ MySQL අනුවාදය තහවුරු කරන්න.

Q2. EXPLAIN ANALYZE ධාවනය කිරීම දත්ත වෙනස් කරද?

A.
EXPLAIN ANALYZE විමසුම අභ්‍යන්තරව ක්‍රියාත්මක කරයි.
SELECT ප්‍රකාශ සමඟ භාවිතා කරන විට, එය දත්ත වෙනස් නොකරයි.

ඒ නිසා, SELECT ප්‍රකාශ සමඟ භාවිතා කරන විට, එය දත්ත වෙනස් නොකරයි.

කෙසේ වෙතත්, ඔබ එය INSERT, UPDATE හෝ DELETE සමඟ වැරදි ලෙස භාවිතා කළහොත්, සාමාන්‍ය විමසුමක් වගේ දත්ත වෙනස් වේ.

ආරක්ෂිත ලෙස, ඉදිරිපත් කිරීමේ පරිසරයට වඩා පරීක්ෂණ හෝ පරික්ෂණ දත්ත ගබඩාවක විශ්ලේෂණය කිරීම සුදුසුය.

Q3. EXPLAIN එකක් පමණක් ප්‍රමාණවත් නොවේද?

A.
EXPLAIN “ඇස්තමේන්තු” ක්‍රියාත්මක සැලසුම සමාලෝචනය සඳහා ප්‍රමාණවත් වේ. කෙසේ වෙතත්, එය වර්තමාන ක්‍රියාත්මක කාලය හෝ වර්තමාන පේළි ගණන වැනි මැනුම් අගයන් ලබා නොදේ.

ඔබට ගැඹුරු විමසුම් සැකසීමක් අවශ්‍ය නම් හෝ අනුකූල කිරීමේ ප්‍රතිඵල තහවුරු කිරීමට අවශ්‍ය නම්, EXPLAIN ANALYZE වඩා ප්‍රයෝජනවත් වේ.

Q4. “loops” සහ “actual time” වැනි අගයන් කොපමණ නිවැරදිද?

A.
actual time සහ loops වැනි අගයන් MySQL අභ්‍යන්තරව මැනූ සැබෑ ක්‍රියාත්මක මිනුම් වේ. කෙසේ වෙතත්, මෙය මෙහෙයුම් පද්ධති තත්ත්ව, කැෂ් තත්ත්ව, සහ සේවාදායක භාරය මත සුළු ලෙස වෙනස් විය හැක.

For this reason, do not rely on a single measurement. Instead, run the query multiple times and evaluate trends.

Q5. “cost” යනු නියමයෙන් කුමක්ද?

A.
cost යනු MySQL හි අභ්‍යන්තර පිරිවැය ආදර්ශය මගින් ගණනය කරන ලද අනුමානිත අගයක් වේ. එය CPU සහ I/O පිරිවැයන්ගේ සාපේක්ෂ ඇගයීම පෙන්වයි. එය තත්පර වලින් ප්‍රකාශ නොකෙරේ.

For example, if you see (cost=0.3) and (cost=2.5), the latter is estimated to be more expensive in relative terms.

Q6. JSON හෝ TREE ආකෘතිය භාවිතා කිරීමේ ප්‍රතිලාභ මොනවාද?

A.

• JSON ආකෘතිය : වැඩසටහන් මගින් පහසුවෙන් විග්‍රහ කළ හැකි සංරචිත ප්‍රතිඵල. ස්වයංක්‍රීය මෙවලම් සහ පුවරුවලට ප්‍රයෝජනවත්.
• TREE ආකෘතිය : ක්‍රියාත්මක ප්‍රවාහය සහ නස්තීරය දෘශ්‍යමයව පැහැදිලි කරයි. සංකීර්ණ විමසුම් සහ JOIN ක්‍රමලේඛය අවබෝධ කර ගැනීමට සුදුසු.

Choose the format that best fits your purpose.

Q7. ක්‍රියාත්මක සැලැස්ම සමාලෝචනය කිරීමෙන් පසු කාර්ය සාධනය වැඩිදියුණු කිරීමට නොහැකි නම් මට මොනවා කළ යුතුද?

A.
Consider additional approaches such as:

• ඉන්ඩෙක්ස් නැවත සැලසුම් කිරීම (සංයුක්ත ඉන්ඩෙක්ස් හෝ ආවරණ ඉන්ඩෙක්ස්)
• විමසුම් නැවත ලිවීම (උපවිමසුම් → JOIN, අවශ්‍ය නොවන SELECT තීරුවල ඉවත් කිරීම)
• දෘශ්‍යයන් හෝ තාවකාලික වගු භාවිතා කිරීම
• MySQL වින්‍යාසය සමාලෝචනය කිරීම (බෆර් ප්‍රමාණ, මතක වෙන් කිරීම, ආදිය)

Performance tuning rarely succeeds with a single technique. A comprehensive and iterative approach is essential.