MyISAM එදිරිව InnoDB [වසා ඇත]


860

මම වැඩ කරන්නේ දත්ත සමුදායන් විශාල ප්‍රමාණයක් ඇතුළත් වන ව්‍යාපෘතියක ය, මම කියමි ( 70% ඇතුළු කිරීම් සහ 30% කියවීම් ). මෙම අනුපාතයට එක් කියවීමක් සහ එක් ලිවීමක් ලෙස මා සලකන යාවත්කාලීන කිරීම් ද ඇතුළත් වේ. කියවීම් අපිරිසිදු විය හැකිය (උදා: කියවන අවස්ථාවේ මට 100% නිවැරදි තොරතුරු අවශ්‍ය නොවේ).
පැයට පැයකට දත්ත සමුදා ගනුදෙනු මිලියනයකට අධික ප්‍රමාණයක් සිදු කරනු ඇත.

MyISAM සහ InnoDB අතර ඇති වෙනස්කම් ගැන මම වෙබයේ දේවල් රාශියක් කියවා ඇති අතර, මෙම කාර්යය සඳහා මා භාවිතා කරන විශේෂිත දත්ත සමුදාය / වගු සඳහා MyISAM මට පැහැදිලිවම තේරීමක් සේ පෙනේ. මා කියවන බව පෙනෙන දෙයින්, පේළි මට්ටමේ අගුලු දැමීම සඳහා සහාය වන බැවින් ගනුදෙනු අවශ්‍ය නම් InnoDB හොඳයි.

මෙම වර්ගයේ බර (හෝ ඊට වැඩි) පිළිබඳ අත්දැකීම් කිසිවෙකුට තිබේද? MyISAM යා යුතු මාර්ගයද?


13
මෙම MySQL කාර්ය සාධන බ්ලොග් දෙයක් මෙම වර්ගය සඳහා විශාල සම්පතකි.
ceejayoz

3
මෙය ඔබගේ පද්ධතිය OLTP හෝ වැඩි දත්ත ගබඩාවක් නැඹුරුද යන්න මත රඳා පවතී (බොහෝ ලිවීම් තොග වශයෙන් පටවන තැන).
අංක

35
MyISAM පේළි අගුළු දැමීම, ගනුදෙනු සඳහා සහය නොදක්වයි, එය විදේශීය යතුරු සඳහා පවා සහාය නොදක්වයි ... නිරය, එයට ACID ලබා දිය නොහැකි බැවින් එය නිසි දත්ත ගබඩාවක් ලෙස සැලකිය නොහැකිය. MySQL 5.5 සිට InnoDB පෙරනිමි එන්ජිම වන්නේ මේ නිසාය ... නමුත්, කුමන හේතුවක් නිසා වුවද, PhpMyAdmin තුළ සාදන ලද වගු සඳහා MyISAM අඛණ්ඩව පෙරනිමි එන්ජිම ලෙස පවතී, එබැවින් MyISAM මත ක්‍රියාත්මක වූ දා සිට බොහෝ ආධුනික දත්ත සමුදායන් ඇත.
බ්ලූරාජා - ඩැනී ප්ලග්ගොෆ්ට්


Answers:


527

මම මෙම ප්‍රශ්නය කෙටියෙන් වගුවක සාකච්ඡා කර ඇති අතර එවිට ඔබට InnoDB හෝ MyISAM සමඟ යා යුතුද යන්න නිගමනය කළ හැකිය .

කුමන තත්වයක් තුළ ඔබ භාවිතා කළ යුතුද යන්න පිළිබඳ කුඩා දළ විශ්ලේෂණයක් මෙන්න:

                                                 MyISAM InnoDB
-------------------------------------------------- --------------
අවශ්‍ය පූර්ණ-පෙළ සෙවීම ඔව් 5.6.4
-------------------------------------------------- --------------
ගනුදෙනු අවශ්‍යයි ඔව්
-------------------------------------------------- --------------
නිතර තෝරාගත් විමසුම් ඔව්      
-------------------------------------------------- --------------
නිතර ඇතුළත් කිරීම, යාවත්කාලීන කිරීම, මකන්න ඔව්
-------------------------------------------------- --------------
පේළි අගුළු දැමීම (තනි වගුවක බහු සැකසුම්) ඔව්
-------------------------------------------------- --------------
සාපේක්ෂ පාදක සැලසුම ඔව්

සාරාංශය

  • සෑම තත්වයකම පාහේ, යන්නට හොඳම ක්‍රමය InnoDB
  • එහෙත්, නිතර කියවීම, ලිවීමක් නැති තරම්ය, MyISAM භාවිතා කරන්න
  • MySQL <= 5.5 හි පූර්ණ-පෙළ සෙවීම, MyISAM භාවිතා කරන්න

11
InnoDB හි MySQL 5.6 හි සම්පූර්ණ පෙළ දර්ශක ඇත, නමුත් මෙතෙක් ඒවා නිෂ්පාදන භාවිතය සඳහා සූදානම් නැත.
බිල් කාර්වින්

3
12.9 ට එකඟ වන්න . පූර්ණ-පෙළ සෙවුම් කාර්යයන් , “පූර්ණ-පෙළ දර්ශක භාවිතා කළ හැක්කේ InnoDB හෝ MyISAM වගු සමඟ පමණි”. MySQL> = 5.6 සඳහා හරි යැයි පෙනේ, කෙසේ වෙතත් MySQL 5.5 සඳහා එකම පිටුව, තවමත් පවසන්නේ “පූර්ණ-පෙළ දර්ශක භාවිතා කළ හැක්කේ MyISAM වගු සමඟ පමණි”. MySQL අනුවාද සමඟ එය වෙනස් වන්නේ කෙසේදැයි පැවසීමට ඉහත වගුව යාවත්කාලීන කළ හැකිය. අවාසනාවකට මෙන්, මෙතෙක්, MySQL 5.5 ප්‍රමිතිය ලෙස පෙනේ.
හිබු 57

2
එයින් අදහස් කරන්නේ කුමක්ද: InnoDB - full-text: 5.6.4?? එය ඔව් ද නැද්ද?

2
MyISAM ද පේළි ගණන අභ්‍යන්තරව ගබඩා කරයි. එබැවින්, ගණන් () ශ්‍රිතය MyISAM හි බොහෝ දුරට නොමිලේ වන අතර, InnoDB හි සැලකිය යුතු කාලයක් ගතවේ.
හෙඩේෂි

3
හොඳ වගුව, නමුත් ගුණාත්මකභාවය සහ ස්ථාවරත්වය සඳහා පේළියක් එක් කිරීම, MyIsam = නැත, අහිංසක ඩී = ඔව් එය වඩාත් හොඳ කරයි
pilavdzice

269

මම දත්ත සමුදා විශේෂ expert යෙක් නොවෙමි, මම අත්දැකීම් වලින් කථා නොකරමි. කෙසේවෙතත්:

MyISAM වගු වගු මට්ටමේ අගුලු දැමීම භාවිතා කරයි . ඔබගේ ගමනාගමන ඇස්තමේන්තු මත පදනම්ව, ඔබට තත්පරයට ලිවීම් 200 කට ආසන්න ප්‍රමාණයක් ඇත. MyISAM සමඟ, ඕනෑම වේලාවක ක්‍රියාත්මක විය හැක්කේ මෙයින් එකක් පමණි . මෙම ගනුදෙනුව ඉක්මවා යාම වළක්වා ගැනීම සඳහා ඔබේ දෘඩාංගයට මෙම ගනුදෙනුව පවත්වා ගෙන යා හැකි බවට ඔබ වග බලා ගත යුතුය, එනම්, එක් විමසුමකට මිනිත්තු 5 කට වඩා ගත නොවේ.

එයින් මට යෝජනා කරන්නේ ඔබට පේළි මට්ටමේ අගුලු දැමීම සඳහා සහාය වන ගබඩා එන්ජිමක් අවශ්‍ය බවයි, එනම් InnoDB.

අනෙක් අතට, එක් එක් ගබඩා එන්ජිම සමඟ බර අනුකරණය කිරීම සඳහා සරල ස්ක්‍රිප්ට් කිහිපයක් ලිවීම තරමක් සුළු විය යුතුය, ඉන්පසු ප්‍රති .ල සංසන්දනය කරන්න.


12
200 ට ආසන්නද? ඔහුගේ සාමාන්‍ය ගනුදෙනුවෙන් විමසුම් 2.5 ක් සිදු වුවහොත්, එය [(2.5 * 1M) / 3600s =] 700 ට ආසන්න වේ.
Ozzy

12
මමත් එකඟ නොවන්නේ a single query can take no more than 5msඔබ උපකල්පන 2 ක් කළ නිසා ය; පිළිතුර: සියලුම විමසුම් වලට එකම වගුවක් අවශ්‍ය විය & බී: තිබුණේ සම්බන්ධතා 1 ක් පමණි! ඉහළ RAM සහිත ලිනක්ස් සහ MySQL 5.5 සැකසුමකට එකවර සම්බන්ධතා 10,000 කට පමණ සහාය විය හැකි බව මම ඔබට දැනුම් දිය යුතුය (බලන්න: dev.mysql.com/doc/refman//5.5/en/too-many-connections.html )
Ozzy

152
වගුවක් අගුළු දමා ඇති විට, එක් වරකට එයට එරෙහිව ධාවනය කළ හැක්කේ එක් විමසුමකට පමණි. සේවාදායකය එකවර සම්බන්ධතා 10000 ක් සඳහා සහය දක්වන්නේද යන්න ගැටළුවක් නොවේ, මේසය අගුළු දමා ඇති විට සෑම එකක්ම උපස්ථ වේ.
රයන්

2
InnoDB සහාය නොදක්වන අතර MyISAM අවකාශීය දර්ශකයට සහය දක්වන බව දැන ගැනීමද ප්‍රයෝජනවත් විය හැකිය. මයිසාම් එකක් නිර්මාණය කිරීම වලක්වා නොගත්තද විදේශීය යතුරු භාවිතා කරන බවක් නොපෙනේ.
ක්‍රිවර්

4
rikriver: ඔබට MyISAM වගු වල විදේශීය යතුරු තිබිය නොහැක. CREATE TABLE ප්‍රකාශ වල ඔබට FK අර්ථ දැක්වීම් ඇතුළත් කළ හැකි නමුත් ඒවා (අර්ථ දැක්වීම්) නොසලකා හරිනු ලැබේ.
ypercubeᵀᴹ

191

මිනිසුන් බොහෝ විට කාර්ය සාධනය ගැන කථා කරයි, එදිරිව ලිවීම්, විදේශීය යතුරු යනාදිය කියවයි. නමුත් මගේ මතය අනුව ගබඩා එන්ජිමක් සඳහා තිබිය යුතු තවත් අංගයක් තිබේ: පරමාණුක යාවත්කාලීන කිරීම්.

මේක උත්සාහ කරන්න:

  1. තත්පර 5 ක් ගතවන ඔබගේ MyISAM වගුවට එරෙහිව යාවත්කාලීනයක් නිකුත් කරන්න.
  2. යාවත්කාලීනය ක්‍රියාත්මක වෙමින් පවතින අතර, තත්පර 2.5 කින් කියන්න, එයට බාධා කිරීමට Ctrl-C ඔබන්න.
  3. මේසය මත ඇති බලපෑම් නිරීක්ෂණය කරන්න. පේළි කීයක් යාවත්කාලීන කරන ලදි? කීයක් යාවත්කාලීන නොකළේ ද? වගුව පවා කියවිය හැකිද, නැතහොත් ඔබ Ctrl-C පහර දුන් විට එය දූෂිතද?
  4. InnoDB වගුවකට එරෙහිව UPDATE සමඟ එකම අත්හදා බැලීම උත්සාහ කරන්න, විමසුම ක්‍රියාත්මක වෙමින් පවතී.
  5. InnoDB වගුව නිරීක්ෂණය කරන්න. ශුන්‍ය පේළි යාවත්කාලීන කරන ලදි. InnoDB ඔබට පරමාණුක යාවත්කාලීනයන් ඇති බවට සහතික වී ඇති අතර, සම්පූර්ණ යාවත්කාලීනය සිදු කළ නොහැකි නම්, එය සමස්ත වෙනසම පෙරළා දමයි. එසේම, මේසය දූෂිත නොවේ. ඔබ killall -9 mysqldබිඳවැටීමක් අනුකරණය කිරීමට භාවිතා කළත් මෙය ක්‍රියාත්මක වේ.

කාර්ය සාධනය ඇත්ත වශයෙන්ම යෝග්‍ය වේ, නමුත් දත්ත අහිමි නොවීම එය තුරන් කළ යුතුය.


4
වාර්තාව සඳහා, ACID දත්ත ගබඩාවක අනෙක් ලක්ෂණ - අනුකූලතාව, හුදකලාව සහ කල්පැවැත්ම - MyISAM විසින් ද සහාය නොදක්වයි.
බිල් කාර්වින්

පාලක-සී වගුව දූෂිත නොකළ යුතුය - චෙක් වගුවේ මෙන් සාර්ථකත්වය නැවත ලැබෙනු ඇති අතර සියලු විමසුම් දෝෂ නොමැතිව ඉදිරියට යනු ඇත. සියලුම වාර්තා යාවත්කාලීන නොකර MyISAM යාවත්කාලීන කිරීම නවතා දමනු ඇත, නමුත් වගුව අභ්‍යන්තර ව්‍යුහාත්මක අඛණ්ඩතාව පවත්වා ගනී. SIGTERM සමඟ mysqld illing ාතනය කිරීම එකම බලපෑමක් ඇති කරයි. කෙසේ වෙතත් ඔබ එයට SIGKILL (kill -9) හෝ යම් බිඳ වැටෙන සං signal ාවක් ලබා දෙන්නේ නම් (හෝ එය දෝෂයකට ලක් වූ විට එය තනිවම උපයා ගනී), හෝ මෙහෙයුම් පද්ධතිය බිඳ වැටීම / බලය නැති වුවහොත් එය වෙනස් කතාවකි - ඔබට දැක ගත හැකිය MyISAM මට්ටමේ දූෂණය.
සාෂා පචෙව්

1
InnoDB හට රාජකීය ලෙසම දූෂිත විය හැකිය, සාමාන්‍යයෙන් MyISAM වලට වඩා රාජකීය ලෙස එය සිදු වේ. ACID හි උත්ප්‍රාසය වන්නේ අපට සියල්ල හෝ කිසිවක් පිළිබඳ සංකල්පයක් තිබීමයි. එබැවින් InnoDB හට සියල්ල ලබා දිය නොහැකි විට, එය කිසිවක් ලබා නොදේ - අභ්‍යන්තර ප්‍රකාශය, එය කිසියම් ව්‍යුහයක එක් බයිට් එකක් වැරදියි - එය කිසිසේත් ධාවනය කිරීම ප්‍රතික්ෂේප කරයි - එය නොසලකා හැරිය හැකි කාලය 90% ක් වන අතර එය බොහෝ විට එක් වගුවකට පමණක් බලපානු ඇත. මෑත පර්කෝනා සේවාදායකයන්ට එය සමඟ ගනුදෙනු කිරීමට විකල්පයක් ඇත - innodb_pass_corrupt_table.
සාෂා පචෙව්

1
මම පසුගිය දින 3 සිට මේ ආකාරයේ තොරතුරු සොයමින් සිටියෙමි, දැන් මට මෙය ලැබුණි. InnoDB හොඳම වේ. ස්තූතියිBill Karwin
user3833682

3
@ flow2k, මේ දිනවල කිසිවක් නැත. මගේ අන්තිම රැකියාවේදී අපි එක් සේවාදායකයක එක් වගුවක් සඳහා MyISAM භාවිතා කළ අතර එකම හේතුව වූයේ InnoDB ට වඩා අඩු ඉඩක එම නිශ්චිත වගුව ගබඩා කිරීමට MyISAM හට හැකි වීමයි. අපට තැටි අවකාශය සීමා වී ඇති බැවින් දත්ත සමුදාය වෙනත් සේවාදායකයකට ගෙන යන තෙක් අපට MyISAM භාවිතා කිරීමට සිදුවිය. මගේ නව රැකියාවේදී, සෑම වගුවක්ම InnoDB විය යුතු බවට ප්‍රතිපත්තියක් දැනටමත් තිබේ.
බිල් කාර්වින්

138

මම MySQL භාවිතා කරමින් ඉහළ පරිමාවකින් යුත් පද්ධතියක වැඩ කර ඇති අතර මම MyISAM සහ InnoDB යන දෙකම අත්හදා බැලුවෙමි.

MyISAM හි වගු මට්ටමේ අගුලු දැමීම අපගේ කාර්ය භාරය සඳහා ඔබට සමාන කාර්ය සාධනයක් ඇති බව මට පෙනී ගියේය. අවාසනාවකට මෙන්, InnoDB යටතේ කාර්ය සාධනය මා බලාපොරොත්තු වූවාට වඩා නරක බව මට පෙනී ගියේය.

අවසානයේදී මම මතභේදාත්මක ගැටළුව නිරාකරණය කළේ දත්ත “ඛණ්ඩනය” කර “උණුසුම්” වගුවකට ඇතුළු වූ අතර කිසි විටෙකත් උණුසුම් වගුව විමසුවේ නැත.

තෝරාගත් විමසීම් මගින් නැවත ස්පර්ශ නොවූ "පරණ" වගු මත මකාදැමීමට (දත්ත කාල සංවේදී වූ අතර අප දින X වටිනාකමක් පමණක් රඳවා තබා ගෙන ඇත). InnoDB තොග මකාදැමීම් වල දුර්වල ක්‍රියාකාරිත්වයක් ඇති බව පෙනේ, එබැවින් ඔබ දත්ත පිරිසිදු කිරීමට සැලසුම් කරන්නේ නම්, පැරණි දත්ත පරණ වගුවක ඇති ආකාරයට එය සැකසීමට ඔබට අවශ්‍ය විය හැකි අතර එය මකාදැමීම වෙනුවට අතහැර දැමිය හැකිය.

ඇත්ත වශයෙන්ම ඔබේ යෙදුම කුමක්දැයි මට අදහසක් නැත, නමුත් මෙය MyISAM සහ InnoDB සමඟ ඇති සමහර ගැටළු පිළිබඳව යම් අවබෝධයක් ලබා දෙනු ඇතැයි අපේක්ෂා කරමු.


3
"අවසානයේදී මම මතභේදාත්මක ගැටළුව විසඳූයේ ඇතුළත් කිරීම්" උණුසුම් "වගුවකට ගොස් කිසි විටෙකත් උණුසුම් වගුව විමසා නැති බව
තෝරා ගනිමිනි

15
ඩැනී - නෑ, ඇත්තටම නැහැ. සේවාදායක සැකසුම් සුසර කිරීම වැදගත්ය, නමුත් ඔබේ ක්‍රමෝපාය කල්පනාකාරීව ව්‍යුහගත කිරීම සඳහා කිසිදු ආකාරයකින් ආදේශකයක් නොවේ. ඔබ සතුව ඩීබී එකක් තිබේ නම්, පවතින RAM වලට වඩා විශාල සහ ප්‍රවේශ රටාවන් අහඹු ලෙස ඩීබී පුරාම ස්පර්ශ වන විට ලෝකයේ සියලුම බෆර් තටාක සුසර කිරීම ඔබට උදව් නොකරනු ඇත. ඔබ දත්ත සහ ප්‍රවේශ රටාවන් තේරුම් ගන්නේ නම් ප්‍රවේශමෙන් සැලසුම් කිරීම තුළින් ඔබට බොහෝ වේදනාවන් අවම කර ගත හැකිය.
alanc10n

66

ක්‍රීඩාවට ටිකක් ප්‍රමාදයි ... නමුත් මෙන්න මම මීට මාස කිහිපයකට පෙර ලිවූ තරමක් සවිස්තරාත්මක ලිපියක් , මයිසෑම් සහ ඉනෝ ඩීබී අතර ඇති ප්‍රධාන වෙනස්කම් විස්තර කරමින්. කෝප්පයක් (සහ සමහර විට බිස්කට් එකක්) අරගෙන විනෝද වන්න.


MyISAM සහ InnoDB අතර ඇති ප්‍රධාන වෙනස වන්නේ යොමු කිරීමේ අඛණ්ඩතාව සහ ගනුදෙනු ය. අගුළු දැමීම, පෙරළීම සහ පූර්ණ-පෙළ සෙවීම් වැනි වෙනත් වෙනසක් ද ඇත.

යොමු අඛණ්ඩතාව

ආශ්‍රිත අඛණ්ඩතාව වගු අතර සම්බන්ධතා ස්ථාවරව පවතින බව සහතික කරයි. වඩාත් නිශ්චිතවම, මෙයින් අදහස් වන්නේ වගුවකට (උදා: ලැයිස්තුගත කිරීම්) විදේශීය යතුරක් (උදා: නිෂ්පාදන හැඳුනුම්පත) වෙනත් වගුවකට යොමු කරන විට (උදා: නිෂ්පාදන), පෙන්වා ඇති වගුවට යාවත්කාලීන කිරීම් හෝ මකාදැමීම් සිදු වූ විට, මෙම වෙනස්කම් සම්බන්ධකයට හසු වේ වගුව. අපගේ උදාහරණයේ දී, නිෂ්පාදනයක් නැවත නම් කළහොත්, සම්බන්ධක වගුවේ විදේශීය යතුරු ද යාවත්කාලීන වේ; 'නිෂ්පාදන' වගුවෙන් නිෂ්පාදනයක් මකා දැමුවහොත්, මකාදැමූ ප්‍රවේශයට යොමු වන ඕනෑම ලැයිස්තුගත කිරීමක් මකා දැමෙනු ඇත. තවද, ඕනෑම නව ලැයිස්තුගත කිරීමකට එම විදේශීය යතුර වලංගු, පවතින ප්‍රවේශයකට යොමු විය යුතුය.

InnoDB යනු සාපේක්ෂ DBMS (RDBMS) වන අතර එමඟින් යොමු යොමු අඛණ්ඩතාව ඇති අතර MyISAM එසේ නොවේ.

ගනුදෙනු සහ පරමාණුකතාව

SELECT, INSERT, UPDATE සහ DELETE වැනි දත්ත හැසිරවීමේ භාෂා (DML) ප්‍රකාශ භාවිතා කරමින් වගුවක දත්ත කළමනාකරණය කෙරේ. ගනුදෙනු කණ්ඩායමක් ඩීඑම්එල් ප්‍රකාශ දෙකක් හෝ වැඩි ගණනක් එක වැඩ ඒකකයකට එකතු කරයි, එබැවින් එක්කෝ මුළු ඒකකයම යෙදේ, නැතහොත් ඒ කිසිවක් නොවේ.

InnoDB සහාය දෙන අතර MyISAM ගනුදෙනු සඳහා සහාය නොදක්වයි.

MyISAM වගුවක් භාවිතා කරන විට මෙහෙයුමකට බාධා ඇති වුවහොත්, මෙහෙයුම වහාම නවතා දමනු ලබන අතර, බලපෑම අවසන් වූ පේළි (හෝ එක් එක් පේළියේ දත්ත පවා) බලපායි.

InnoDB වගුවක් භාවිතා කරන විට මෙහෙයුමකට බාධා ඇති වුවහොත්, එය පරමාණුකතාව ඇති ගනුදෙනු භාවිතා කරන නිසා, කිසිදු ගනුදෙනුවක් සිදු නොවන බැවින්, සම්පූර්ණ කිරීමට නොගිය ඕනෑම ගනුදෙනුවක් බලාත්මක නොවේ.

පේළි අගුලු දැමීමට එදිරිව වගු අගුලු දැමීම

විමසුමක් MyISAM වගුවකට එරෙහිව ක්‍රියාත්මක වන විට, එය විමසන මුළු වගුවම අගුළු දමා ඇත. මෙයින් අදහස් කරන්නේ පසුකාලීන විමසුම් ක්‍රියාත්මක වන්නේ වත්මන් ප්‍රශ්නය අවසන් වූ පසුව පමණක් බවයි. ඔබ විශාල වගුවක් කියවනවා නම් සහ / හෝ නිතර කියවීමේ හා ලිවීමේ මෙහෙයුම් තිබේ නම්, මෙයින් අදහස් කරන්නේ විමසීම්වල විශාල පසුබෑමකි.

InnoDB වගුවකට එරෙහිව විමසුමක් ක්‍රියාත්මක වන විට, සම්බන්ධ වී ඇති පේළි (ය) පමණක් අගුළු දමා ඇති අතර, ඉතිරි වගුව CRUD මෙහෙයුම් සඳහා පවතී. මෙයින් අදහස් කරන්නේ විමසුම් එකම පේළියක් භාවිතා නොකරන්නේ නම් එකවර එකම වගුවක ධාවනය කළ හැකි බවයි.

InnoDB හි මෙම අංගය සමගාමී මුදල් ලෙස හැඳින්වේ. සමගාමී මුදල් තරම් විශාල, තෝරාගත් වගු පරාසයකට අදාළ වන විශාල අඩුපාඩුවක් ඇත, එහි කර්නල් නූල් අතර මාරුවීමේ පොදු කාර්යයක් ඇති අතර, සේවාදායකය නතර වීම වැළැක්වීම සඳහා ඔබ කර්නල් නූල් සඳහා සීමාවක් නියම කළ යුතුය. .

ගනුදෙනු සහ පෙරළීම්

ඔබ MyISAM හි මෙහෙයුමක් ක්‍රියාත්මක කරන විට, වෙනස්කම් සකසා ඇත; InnoDB හි, එම වෙනස්කම් නැවත පෙරළා දැමිය හැකිය. ගනුදෙනු පාලනය කිරීම සඳහා භාවිතා කරන වඩාත් පොදු විධානයන් වන්නේ COMMIT, ROLLBACK සහ SAVEPOINT ය. 1. COMMIT - ඔබට බහු ඩීඑම්එල් මෙහෙයුම් ලිවිය හැකිය, නමුත් වෙනස්කම් සුරැකෙන්නේ COMMIT එකක් සෑදූ විට පමණි 2. රෝල්බැක් - ඔබට තවමත් සිදු කර නොමැති ඕනෑම මෙහෙයුමක් ඉවත දැමිය හැකිය 3. SAVEPOINT - ලැයිස්තුවේ ලක්ෂ්‍යයක් නියම කරයි ROLLBACK මෙහෙයුමකට ආපසු යා හැකි මෙහෙයුම්

විශ්වසනීයත්වය

MyISAM කිසිදු දත්ත අඛණ්ඩතාවයක් ඉදිරිපත් නොකරයි - දෘඩාංග අසමත්වීම්, අපිරිසිදු වසා දැමීම් සහ අවලංගු කරන ලද මෙහෙයුම් මගින් දත්ත දූෂිත වීමට හේතු වේ. මේ සඳහා දර්ශක සහ වගු සම්පූර්ණයෙන් අළුත්වැඩියා කිරීම හෝ නැවත ගොඩනැඟීම අවශ්‍ය වේ.

InnoDB, අනෙක් අතට, දූෂණ වැළැක්වීම සඳහා ගනුදෙනු ලොගයක්, ද්වි-ලිවීමේ බෆරයක් සහ ස්වයංක්‍රීය චෙක්පත් කිරීම සහ වලංගුකරණය භාවිතා කරයි. InnoDB කිසියම් වෙනසක් කිරීමට පෙර, එය ගනුදෙනු කිරීමට පෙර දත්ත ibdata1 නමින් පද්ධති වගු ගොනුවකට වාර්තා කරයි. බිඳවැටීමක් සිදුවුවහොත්, එම ල .ු-සටහන් නැවත ධාවනය කිරීමෙන් InnoDB ස්වයංක්‍රීයව සොයා ගනී.

FULLTEXT සුචිගත කිරීම

MySQL අනුවාදය 5.6.4 වන තෙක් InnoDB FULLTEXT සුචිගත කිරීම සඳහා සහය නොදක්වයි. මෙම ලිපිය ලියන විට, බොහෝ හවුල් සත්කාරක සැපයුම්කරුවන්ගේ MySQL අනුවාදය තවමත් 5.6.4 ට වඩා පහළින් පවතී, එයින් අදහස් වන්නේ InnoDB වගු සඳහා FULLTEXT සුචිගත කිරීම සහාය නොදක්වන බවයි.

කෙසේ වෙතත්, මෙය MyISAM භාවිතා කිරීමට වලංගු හේතුවක් නොවේ. MySQL හි යාවත්කාලීන අනුවාදයන්ට සහය දක්වන සත්කාරක සැපයුම්කරුවෙකු වෙත වෙනස් වීම වඩාත් සුදුසුය. FULLTEXT සුචිගත කිරීම භාවිතා කරන MyISAM වගුවක් InnoDB වගුවකට පරිවර්තනය කළ නොහැකි බව නොවේ.

නිගමනය

අවසාන වශයෙන්, InnoDB ඔබේ සුපුරුදු ගබඩා එන්ජිම විය යුතුය. නිශ්චිත අවශ්‍යතාවයක් ඉටු කරන විට MyISAM හෝ වෙනත් දත්ත වර්ග තෝරන්න.


මම පීඑච්පී සැසි චෙක්සම් ස්ක්‍රිප්ට් එකක් සාදන අතර මගේ යතුර බොහෝමයක් අහඹු ලෙස [az09] වේ ... ඉනොඩ්බ් මීටර් 30 කට වඩා වැඩි කාලයක් ගත කළේය. INSERT ON DUPLICATE KEY UPDATEඒ නිසා මම මයිසෑම් අත්හදා බැලුවෙමි. දැන් එය <1 මි.මී. 'නොවරදින' (අහඹු නූල්) අද්විතීය යතුරු සමඟ කටයුතු කිරීමට innodb හට අසීරු කාලයක් තිබේ ... ඒ සඳහා ඔබට කිසියම් ආදානයක් තිබේද? ඇත්ත වශයෙන්ම මම කල්පනා කරමින් සිටියේ එයට MyISAM භාවිතා කිරීමට සිදුවන බලපෑම ගැන නමුත් ඔබේ විශිෂ්ට පිළිතුර මට වැටහී ගියේ එය එම විශේෂිත අවස්ථාව සඳහා යා යුතු මාර්ගය බවයි.
ලුවී ලොඩෝග් ට්‍රොට්ටියර්

64

වැඩි ලිවීම් සහ කියවීම් සහිත බරක් සඳහා, ඔබට InnoDB වෙතින් ප්‍රතිලාභ ලැබෙනු ඇත. InnoDB වගු අගුළු දැමීම වෙනුවට පේළි අගුළු දැමීම සපයන හෙයින්, ඔබේ SELECTඒවා එකිනෙකට පමණක් නොව බොහෝ INSERTs සමඟ සමගාමී විය හැකිය . කෙසේ වෙතත්, ඔබ SQL ගනුදෙනු භාවිතා කිරීමට අදහස් නොකරන්නේ නම්, InnoDB බැඳීමේ ෆ්ලෂ් 2 ට සකසන්න ( innodb_flush_log_at_trx_commit ). MyISAM සිට InnoDB වෙත වගු ගෙන යන විට ඔබට නැතිවිය හැකි අමු කාර්ය සාධනය මෙය නැවත ලබා දෙයි.

එසේම, අනුරූකරණයක් එකතු කිරීම සලකා බලන්න. මෙය ඔබට කියවීමේ පරිමාණයන් ලබා දෙන අතර ඔබේ කියවීම් යාවත්කාලීන විය යුතු නැති බව ඔබ ප්‍රකාශ කළ බැවින්, අනුරූකරණය මඳක් පසුබෑමට ඉඩ දිය හැකිය. අධික වාහන තදබදය හැර වෙනත් ඕනෑම දෙයකට එය හසු කර ගත හැකි බවට වග බලා ගන්න හෝ එය සැමවිටම පිටුපසින් සිටින අතර කිසි විටෙකත් අල්ලා නොගනී. කෙසේ වෙතත්, ඔබ මේ ආකාරයට ගියහොත් , වහලුන්ගෙන් කියවීම හුදකලා කිරීම සහ ප්‍රතිවිකුණුම් පසුගාමී කළමනාකරණය ඔබේ දත්ත සමුදා හසුරුවන්නාට වෙන් කිරීමට මම තරයේ නිර්දේශ කරමි. යෙදුම් කේතය මේ ගැන නොදන්නේ නම් එය එතරම් සරල ය.

අවසාන වශයෙන්, විවිධ වගු පැටවීම් ගැන සැලකිලිමත් වන්න. සියලුම වගු වල ඔබට එකම කියවීමේ / ලිවීමේ අනුපාතය නොමැත. 100% කට ආසන්න කියවීම් සහිත සමහර කුඩා වගු වලට MyISAM හි රැඳී සිටීමට හැකිය. ඒ හා සමානව, ඔබ සතුව 100% ලිවීමට ආසන්න වගු කිහිපයක් තිබේ නම්, ඔබට එයින් ප්‍රයෝජන ලැබිය හැකිය INSERT DELAYED, නමුත් එය සහාය දක්වන්නේ MyISAM හි පමණි ( DELAYEDInnoDB වගුවක් සඳහා වගන්තිය නොසලකා හරිනු ලැබේ).

නමුත් සහතික විය යුතු මිණුම් ලකුණ.


4
ඔබ සඳහන් කරන "InnoDB commit flush" ද innodb_flush_log_at_trx_commit?
ceejayoz

2
මට ඔබගේ ලිපිය ඉතා ප්‍රයෝජනවත් විය - ස්තූතියි. මගේ වගු සඳහා MyISAM / InnoDB භාවිතා කළ යුත්තේ කවදාදැයි තක්සේරු කිරීම සහ ඔබගේ ලිපිය ප්‍රයෝජනවත් විය. චියර්ස්.
starmonkey

2
dev.mysql.com/doc/refman/5.5/en/insert-delayed.html මෙසේ සඳහන් කරයි: MyISAM වගු සඳහා, දත්ත ගොනුව මැද නිදහස් වාරණ නොමැති නම්, සමගාමී SELECT සහ INSERT ප්‍රකාශ සඳහා සහය දක්වයි. මෙම තත්වයන් යටතේ, ඔබ ඉතා කලාතුරකින් MyISAM සමඟ INSERT DELAYED භාවිතා කිරීම අවශ්‍ය වේ.
tymtam

ඉතා තොරතුරු සහිත තනතුරක්. මට දෘෂ්ටි කෝණයෙන් සමාන ප්‍රශ්නයක් ඇති අතර මට කියන්නට ඇත්තේ ඔබගේ දත්ත ගබඩාව මගේ දත්ත සමුදා එන්ජින් තීරණය ගැන මට පහසුවක් වී ඇති බවයි. ස්තූතියි! ++
ජෝ මජෙව්ස්කි

ඉක්මන් සටහන: ප්‍රමාද වීම 5.7 හි තවදුරටත් සහාය නොදක්වයි. ඒ වෙනුවට ඔබට LOW_PRIORITY සමඟ පරීක්ෂා කිරීමට අවශ්‍ය විය හැකිය.
වෙබ්මාට්

59

එන්ජින් දෙක අතර යාන්ත්‍රික වෙනස්කම් ආවරණය වන පරිදි මෙහි පුළුල් ප්‍රතිචාර වලට එකතු කිරීම සඳහා, මම ආනුභවික වේග සංසන්දනය අධ්‍යයනයක් ඉදිරිපත් කරමි.

පිරිසිදු වේගය සම්බන්ධයෙන් ගත් කල, මයිසෑම් ඉනෝ ඩීබී වලට වඩා වේගවත් බව සැමවිටම නොවේ, නමුත් මගේ අත්දැකීම් අනුව එය පිරිසිදු පරිසරය සඳහා 2.0-2.5 ගුණයක සාධකයකින් වේගවත් වේ. පැහැදිලිවම මෙය සියලු පරිසරයන්ට සුදුසු නොවේ - අනෙක් අය ලියා ඇති පරිදි, ගනුදෙනු සහ විදේශීය යතුරු වැනි දේ MyISAM හි නොමැත.

මම පහතින් මිණුම් සලකුණු කිරීමක් කර ඇත - මම ලූප් කිරීම සඳහා පයිතන් සහ කාල සැසඳීම් සඳහා කාල පුස්තකාලය භාවිතා කර ඇත්තෙමි. උනන්දුව සඳහා මම මතක එන්ජිමද ඇතුළත් කර ඇති අතර, මෙය කුඩා වගු සඳහා පමණක් සුදුසු වුවද පුවරුව හරහා හොඳම කාර්ය සාධනය ලබා දෙයි (ඔබ The table 'tbl' is fullMySQL මතක සීමාව ඉක්මවා යන විට ඔබට නිරන්තරයෙන් හමු වේ ). මා බලන තෝරාගත් වර්ග හතර නම්:

  1. වැනිලා තේරීම්
  2. ගණන්
  3. කොන්දේසි සහිත තේරීම්
  4. සුචිගත කළ සහ සුචිගත නොකළ උප තේරීම්

පළමුව, මම පහත SQL භාවිතා කරමින් වගු තුනක් නිර්මාණය කළෙමි

CREATE TABLE
    data_interrogation.test_table_myisam
    (
        index_col BIGINT NOT NULL AUTO_INCREMENT,
        value1 DOUBLE,
        value2 DOUBLE,
        value3 DOUBLE,
        value4 DOUBLE,
        PRIMARY KEY (index_col)
    )
    ENGINE=MyISAM DEFAULT CHARSET=utf8

දෙවන හා තෙවන වගු වල 'InnoDB' සහ 'මතකය' සඳහා ආදේශ කර ඇති 'MyISAM' සමඟ.

 

1) වැනිලා තෝරා ගනී

විමසුම: SELECT * FROM tbl WHERE index_col = xx

ප්‍රති ult ලය: අදින්න

විවිධ දත්ත සමුදා එන්ජින් මගින් වැනිලා තේරීම් සංසන්දනය කිරීම

මේ සියල්ලේ වේගය පුළුල් ලෙස සමාන වන අතර අපේක්ෂිත පරිදි තෝරා ගත යුතු තීරු ගණනෙහි රේඛීය වේ. InnoDB MyISAM ට වඩා තරමක් වේගවත් බව පෙනේ, නමුත් මෙය සැබවින්ම ආන්තිකය.

කේතය:

import timeit
import MySQLdb
import MySQLdb.cursors
import random
from random import randint

db = MySQLdb.connect(host="...", user="...", passwd="...", db="...", cursorclass=MySQLdb.cursors.DictCursor)
cur = db.cursor()

lengthOfTable = 100000

# Fill up the tables with random data
for x in xrange(lengthOfTable):
    rand1 = random.random()
    rand2 = random.random()
    rand3 = random.random()
    rand4 = random.random()

    insertString = "INSERT INTO test_table_innodb (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")"
    insertString2 = "INSERT INTO test_table_myisam (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")"
    insertString3 = "INSERT INTO test_table_memory (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")"

    cur.execute(insertString)
    cur.execute(insertString2)
    cur.execute(insertString3)

db.commit()

# Define a function to pull a certain number of records from these tables
def selectRandomRecords(testTable,numberOfRecords):

    for x in xrange(numberOfRecords):
        rand1 = randint(0,lengthOfTable)

        selectString = "SELECT * FROM " + testTable + " WHERE index_col = " + str(rand1)
        cur.execute(selectString)

setupString = "from __main__ import selectRandomRecords"

# Test time taken using timeit
myisam_times = []
innodb_times = []
memory_times = []

for theLength in [3,10,30,100,300,1000,3000,10000]:

    innodb_times.append( timeit.timeit('selectRandomRecords("test_table_innodb",' + str(theLength) + ')', number=100, setup=setupString) )
    myisam_times.append( timeit.timeit('selectRandomRecords("test_table_myisam",' + str(theLength) + ')', number=100, setup=setupString) )
    memory_times.append( timeit.timeit('selectRandomRecords("test_table_memory",' + str(theLength) + ')', number=100, setup=setupString) )

 

2) ගණන්

විමසුම: SELECT count(*) FROM tbl

ප්‍රති ult ලය : MyISAM ජය ගනී

විවිධ දත්ත සමුදා එන්ජින් ගණනය කිරීම් සංසන්දනය කිරීම

මෙය MyISAM සහ InnoDB අතර විශාල වෙනසක් පෙන්නුම් කරයි - MyISAM (සහ මතකය) වගුවේ ඇති වාර්තා ගණන නිරීක්ෂණය කරයි, එබැවින් මෙම ගනුදෙනුව වේගවත් වන අතර O (1) වේ. InnoDB ගණනය කිරීම සඳහා ගතවන කාලය මා විමර්ශනය කළ පරාසය තුළ වගු ප්‍රමාණය සමඟ සුපිරි රේඛීයව වැඩි වේ. ප්‍රායෝගිකව නිරීක්ෂණය කරන ලද MyISAM විමසුම් වල වේගවත් කිරීම් බොහෝමයක් සමාන බලපෑම් නිසා ඇති වූවක් යැයි මම සැක කරමි.

කේතය:

myisam_times = []
innodb_times = []
memory_times = []

# Define a function to count the records
def countRecords(testTable):

    selectString = "SELECT count(*) FROM " + testTable
    cur.execute(selectString)

setupString = "from __main__ import countRecords"

# Truncate the tables and re-fill with a set amount of data
for theLength in [3,10,30,100,300,1000,3000,10000,30000,100000]:

    truncateString = "TRUNCATE test_table_innodb"
    truncateString2 = "TRUNCATE test_table_myisam"
    truncateString3 = "TRUNCATE test_table_memory"

    cur.execute(truncateString)
    cur.execute(truncateString2)
    cur.execute(truncateString3)

    for x in xrange(theLength):
        rand1 = random.random()
        rand2 = random.random()
        rand3 = random.random()
        rand4 = random.random()

        insertString = "INSERT INTO test_table_innodb (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")"
        insertString2 = "INSERT INTO test_table_myisam (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")"
        insertString3 = "INSERT INTO test_table_memory (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")"

        cur.execute(insertString)
        cur.execute(insertString2)
        cur.execute(insertString3)

    db.commit()

    # Count and time the query
    innodb_times.append( timeit.timeit('countRecords("test_table_innodb")', number=100, setup=setupString) )
    myisam_times.append( timeit.timeit('countRecords("test_table_myisam")', number=100, setup=setupString) )
    memory_times.append( timeit.timeit('countRecords("test_table_memory")', number=100, setup=setupString) )

 

3) කොන්දේසි සහිත තේරීම්

විමසුම: SELECT * FROM tbl WHERE value1<0.5 AND value2<0.5 AND value3<0.5 AND value4<0.5

ප්‍රති ult ලය : MyISAM ජය ගනී

විවිධ දත්ත සමුදා එන්ජින් මගින් කොන්දේසි සහිත තේරීම් සංසන්දනය කිරීම

මෙන්න, MyISAM සහ මතකය දළ වශයෙන් එක හා සමාන වන අතර විශාල වගු සඳහා InnoDB 50% කින් පරාජය කරන්න. MyISAM හි ප්‍රතිලාභ උපරිම ලෙස පෙනෙන ආකාරයේ විමසුම මෙයයි.

කේතය:

myisam_times = []
innodb_times = []
memory_times = []

# Define a function to perform conditional selects
def conditionalSelect(testTable):
    selectString = "SELECT * FROM " + testTable + " WHERE value1 < 0.5 AND value2 < 0.5 AND value3 < 0.5 AND value4 < 0.5"
    cur.execute(selectString)

setupString = "from __main__ import conditionalSelect"

# Truncate the tables and re-fill with a set amount of data
for theLength in [3,10,30,100,300,1000,3000,10000,30000,100000]:

    truncateString = "TRUNCATE test_table_innodb"
    truncateString2 = "TRUNCATE test_table_myisam"
    truncateString3 = "TRUNCATE test_table_memory"

    cur.execute(truncateString)
    cur.execute(truncateString2)
    cur.execute(truncateString3)

    for x in xrange(theLength):
        rand1 = random.random()
        rand2 = random.random()
        rand3 = random.random()
        rand4 = random.random()

        insertString = "INSERT INTO test_table_innodb (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")"
        insertString2 = "INSERT INTO test_table_myisam (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")"
        insertString3 = "INSERT INTO test_table_memory (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")"

        cur.execute(insertString)
        cur.execute(insertString2)
        cur.execute(insertString3)

    db.commit()

    # Count and time the query
    innodb_times.append( timeit.timeit('conditionalSelect("test_table_innodb")', number=100, setup=setupString) )
    myisam_times.append( timeit.timeit('conditionalSelect("test_table_myisam")', number=100, setup=setupString) )
    memory_times.append( timeit.timeit('conditionalSelect("test_table_memory")', number=100, setup=setupString) )

 

4) උප තේරීම්

ප්‍රති ult ලය : InnoDB ජය ගනී

මෙම විමසුම සඳහා, මම උප තේරීම සඳහා අතිරේක වගු මාලාවක් නිර්මාණය කළෙමි. සෑම එකක්ම BIGINT තීරු දෙකකි, එකක් ප්‍රාථමික යතුරු දර්ශකයක් සහ එකක් දර්ශකයක් නොමැතිව. විශාල වගු ප්‍රමාණය නිසා, මම මතක එන්ජිම පරීක්ෂා කළේ නැත. SQL වගු නිර්මාණය කිරීමේ විධානය විය

CREATE TABLE
    subselect_myisam
    (
        index_col bigint NOT NULL,
        non_index_col bigint,
        PRIMARY KEY (index_col)
    )
    ENGINE=MyISAM DEFAULT CHARSET=utf8;

එහිදී නැවත වරක්, දෙවන වගුවේ 'InnoDB' සඳහා 'MyISAM' ආදේශ කරනු ලැබේ.

මෙම විමසුමේදී, මම තේරීම් වගුවේ ප්‍රමාණය 1000000 ට තබන අතර ඒ වෙනුවට උප-තෝරාගත් තීරුවල ප්‍රමාණය වෙනස් වේ.

විවිධ දත්ත සමුදා එන්ජින් මගින් උප-තේරීම් සංසන්දනය කිරීම

මෙන්න InnoDB පහසුවෙන් ජය ගනී. අපි සාධාරණ ප්‍රමාණයේ වගුවකට ගිය පසු එන්ජින් දෙකම උප තේරීමේ ප්‍රමාණය සමඟ රේඛීයව පරිමාණය කරයි. දර්ශකය MyISAM විධානය වේගවත් කරන නමුත් සිත්ගන්නා කරුණ නම් InnoDB වේගයට එතරම් බලපෑමක් නැත. subSelect.png

කේතය:

myisam_times = []
innodb_times = []
myisam_times_2 = []
innodb_times_2 = []

def subSelectRecordsIndexed(testTable,testSubSelect):
    selectString = "SELECT * FROM " + testTable + " WHERE index_col in ( SELECT index_col FROM " + testSubSelect + " )"
    cur.execute(selectString)

setupString = "from __main__ import subSelectRecordsIndexed"

def subSelectRecordsNotIndexed(testTable,testSubSelect):
    selectString = "SELECT * FROM " + testTable + " WHERE index_col in ( SELECT non_index_col FROM " + testSubSelect + " )"
    cur.execute(selectString)

setupString2 = "from __main__ import subSelectRecordsNotIndexed"

# Truncate the old tables, and re-fill with 1000000 records
truncateString = "TRUNCATE test_table_innodb"
truncateString2 = "TRUNCATE test_table_myisam"

cur.execute(truncateString)
cur.execute(truncateString2)

lengthOfTable = 1000000

# Fill up the tables with random data
for x in xrange(lengthOfTable):
    rand1 = random.random()
    rand2 = random.random()
    rand3 = random.random()
    rand4 = random.random()

    insertString = "INSERT INTO test_table_innodb (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")"
    insertString2 = "INSERT INTO test_table_myisam (value1,value2,value3,value4) VALUES (" + str(rand1) + "," + str(rand2) + "," + str(rand3) + "," + str(rand4) + ")"

    cur.execute(insertString)
    cur.execute(insertString2)

for theLength in [3,10,30,100,300,1000,3000,10000,30000,100000]:

    truncateString = "TRUNCATE subselect_innodb"
    truncateString2 = "TRUNCATE subselect_myisam"

    cur.execute(truncateString)
    cur.execute(truncateString2)

    # For each length, empty the table and re-fill it with random data
    rand_sample = sorted(random.sample(xrange(lengthOfTable), theLength))
    rand_sample_2 = random.sample(xrange(lengthOfTable), theLength)

    for (the_value_1,the_value_2) in zip(rand_sample,rand_sample_2):
        insertString = "INSERT INTO subselect_innodb (index_col,non_index_col) VALUES (" + str(the_value_1) + "," + str(the_value_2) + ")"
        insertString2 = "INSERT INTO subselect_myisam (index_col,non_index_col) VALUES (" + str(the_value_1) + "," + str(the_value_2) + ")"

        cur.execute(insertString)
        cur.execute(insertString2)

    db.commit()

    # Finally, time the queries
    innodb_times.append( timeit.timeit('subSelectRecordsIndexed("test_table_innodb","subselect_innodb")', number=100, setup=setupString) )
    myisam_times.append( timeit.timeit('subSelectRecordsIndexed("test_table_myisam","subselect_myisam")', number=100, setup=setupString) )
        
    innodb_times_2.append( timeit.timeit('subSelectRecordsNotIndexed("test_table_innodb","subselect_innodb")', number=100, setup=setupString2) )
    myisam_times_2.append( timeit.timeit('subSelectRecordsNotIndexed("test_table_myisam","subselect_myisam")', number=100, setup=setupString2) )

මම හිතන්නේ මේ සියල්ලේ ගෙදර ගෙන යාමේ පණිවිඩය නම් ඔබ වේගය ගැන සැබවින්ම සැලකිලිමත් වන්නේ නම් , කුමන එන්ජිම වඩාත් සුදුසු වනු ඇත්දැයි උපකල්පන කරනවාට වඩා ඔබ කරන විමසුම් මිණුම් සලකුණු කළ යුතුය.


1
කාර්ය සාධනය සැමවිටම එකම සලකා බැලීම නොවේ, ස්ථායිතාව පිළිබඳ ප්‍රස්ථාරයක් ගැන කුමක් කිව හැකිද? එන්ජිමක් කඩා වැටී මූලික දත්ත සමුදා විශේෂාංග සඳහා සහය නොදක්වන්නේ නම් කිසිවක් සඳහා හොඳ නැත.
pilavdzice

1
InnoDB සඳහා my.cnfගොනුව ප්‍රශස්තිකරණය නොකළහොත් බොහෝ විට MyISAM විසින් InnoDB පරාජය කරනු ඇත . ඔබේ my.cnfගොනුව පෙනෙන්නේ කෙසේදැයි ඔබ සඳහන් කර නැත , එය ඇත්ත වශයෙන්ම InnoDB කාර්ය සාධනය සඳහා වැදගත්ම සාධකය වේ.
itoctopus

ස්තූතියි ඉටෝටෝපස් - ඔබ නිර්දේශ කරන ඕනෑම ප්‍රශස්තිකරණයන් ගැන වැඩි විස්තර දැනගැනීමට මා කැමතිය. මෙම පරීක්ෂණ සඳහා භාවිතා කරන ලද සම්පූර්ණ කේතය ඉහළින් ඇත, විවිධ ප්‍රශස්තිකරණයන් සමඟ අත්හදා බැලීම් නැවත කිරීමට නිදහස්ව සිටින්න සහ
ප්‍රති come ලවල

33

තරමක් මාතෘකාවෙන් තොර නමුත් ලේඛනගත කිරීමේ අරමුණු සහ සම්පූර්ණත්වය සඳහා මම පහත සඳහන් දෑ එකතු කිරීමට කැමැත්තෙමි.

පොදුවේ ගත් කල, InnoDB භාවිතා කිරීමෙන් අඩු සංකීර්ණ යෙදුමක් ලැබෙනු ඇත, බොහෝ විට දෝෂ රහිත වේ. ඔබට සියලු යොමු අඛණ්ඩතාව (විදේශීය යතුරු අවහිරතා) දත්ත මොඩලයට දැමිය හැකි බැවින්, ඔබට MyISAM සමඟ අවශ්‍ය වන තරම් යෙදුම් කේතයක් අසල කොතැනකවත් අවශ්‍ය නොවේ.

ඔබ වාර්තාවක් ඇතුළත් කරන විට, මකා දැමූ හෝ ප්‍රතිස්ථාපනය කරන සෑම අවස්ථාවකම, ඔබ සම්බන්ධතා පරීක්ෂා කර පවත්වා ගෙන යනු ඇත. උදා: ඔබ දෙමාපියෙකු මකා දැමුවහොත්, සියලු දරුවන් ද මකා දැමිය යුතුය. නිදසුනක් ලෙස, සරල බ්ලොග්කරණ පද්ධතියක වුවද, ඔබ බ්ලොග් පෝස්ට් වාර්තාවක් මකා දැමුවහොත්, ඔබට අදහස් වාර්තා, රුචි අරුචිකම් මකා දැමීමට සිදුවේ. InnoDB හි මෙය ස්වයංක්‍රීයව දත්ත සමුදා එන්ජිම මඟින් සිදු කරයි (ඔබ ආකෘතියේ ප්‍රතිවිරෝධතා නියම කර ඇත්නම් ) සහ යෙදුම් කේතයක් අවශ්‍ය නොවේ. MyISAM හි මෙය යෙදුමට කේත කිරීමට සිදුවනු ඇත, එය වෙබ් සේවාදායකයන්හි ඉතා අපහසු වේ. වෙබ් සේවාදායකයන් ස්වභාවයෙන්ම ඉතා සමගාමී / සමාන්තර වන අතර මෙම ක්‍රියා පරමාණුක විය යුතු අතර MyISAM සැබෑ ගනුදෙනු සඳහා සහාය නොදක්වන හෙයින්, වෙබ් සේවාදායකයන් සඳහා MyISAM භාවිතා කිරීම අවදානම් / දෝෂ සහිත වේ.

බොහෝ සාමාන්‍ය අවස්ථාවන්හිදී, InnoDB වඩා හොඳ ප්‍රති perform ල ලබා දෙනු ඇත, හේතු කිහිපයක් නිසා, ඒවායින් එකක් මේස මට්ටමේ අගුලු දැමීමට වඩා වාර්තා මට්ටමේ අගුලු දැමීම භාවිතා කළ හැකිය. කියවීමට වඩා නිතර ලිවීම් සිදුවන තත්වයක පමණක් නොව, විශාල දත්ත කට්ටලවල සංකීර්ණ සම්බන්ධතා ඇති අවස්ථාවන්හිදී ද. ඉතා විශාල බැඳීම් සඳහා (මිනිත්තු කිහිපයක් ගතවීම) MyISAM වගු වලට වඩා InnoDB වගු භාවිතා කිරීමෙන් 3 ගුණයක කාර්යසාධනයක් අපි දුටුවෙමු.

MySQL භාවිතා කරන විට සාමාන්‍යයෙන් InnoDB (3NF datamodel සම්පුර්ණ යොමු යොමු අඛණ්ඩතාවයකින් භාවිතා කිරීම) පෙරනිමි තේරීම විය යුතු යැයි මම කියමි. MyISAM භාවිතා කළ යුත්තේ ඉතා සුවිශේෂී අවස්ථාවන්හිදී පමණි. එය බොහෝ දුරට අඩු කාර්ය සාධනයක් වනු ඇත, එහි ප්‍රති result ලය වනුයේ විශාල හා වඩා දෝෂ සහිත යෙදුමකි.

මෙය පවසා තිබීම. ඩේටාමොඩෙලිං යනු වෙබ් නිර්මාණකරුවන් / වැඩසටහන්කරුවන් අතර කලාතුරකින් දක්නට ලැබෙන කලාවකි. වරදක් නැත, නමුත් එය පැහැදිලි කරන්නේ MyISAM මෙතරම් භාවිතා වන බවයි.


31

InnoDB පිරිනැමීම්:

ACID transactions
row-level locking
foreign key constraints
automatic crash recovery
table compression (read/write)
spatial data types (no spatial indexes)

InnoDB හි TEXT සහ BLOB හැර අනෙක් සියලුම දත්ත වලට බයිට් 8,000 ක් උපරිම වශයෙන් ලබා ගත හැකිය. InnoDB සඳහා සම්පූර්ණ පෙළ සුචිගත කිරීමක් නොමැත. InnoDB හි COUNT (*) s (WHERE, GROUP BY, හෝ JOIN භාවිතා නොකරන විට) MyISAM වලට වඩා මන්දගාමීව ක්‍රියාත්මක වන්නේ පේළි ගණන අභ්‍යන්තරව ගබඩා නොවන බැවිනි. InnoDB දත්ත සහ දර්ශක දෙකම එක් ගොනුවක ගබඩා කරයි. InnoDB දත්ත සහ දර්ශක යන දෙකම හැඹිලි කිරීමට ස්වාරක්ෂක තටාකයක් භාවිතා කරයි.

MyISAM ඉදිරිපත් කරයි:

fast COUNT(*)s (when WHERE, GROUP BY, or JOIN is not used)
full text indexing
smaller disk footprint
very high table compression (read only)
spatial data types and indexes (R-tree)

MyISAM සතුව වගු මට්ටමේ අගුලු ඇත, නමුත් පේළි මට්ටමේ අගුළු නොමැත. ගනුදෙනු නොමැත. ස්වයංක්‍රීය බිඳවැටීම් ප්‍රතිසාධනයක් නොමැත, නමුත් එය අළුත්වැඩියා වගු ක්‍රියාකාරිත්වය සපයයි. විදේශීය යතුරු අවහිරතා නොමැත. InnoDB වගු හා සසඳන විට MyISAM වගු සාමාන්‍යයෙන් තැටියේ ප්‍රමාණයට වඩා සංයුක්ත වේ. අවශ්‍ය නම් myisampack සමඟ සම්පීඩනය කිරීමෙන් MyISAM වගු ප්‍රමාණයෙන් වැඩි කළ හැකි නමුත් කියවීමට පමණි. MyISAM දර්ශක එක් ගොනුවක සහ දත්ත තවත් ගොනුවක ගබඩා කරයි. MyISAM දර්ශක හැඹිලි සඳහා යතුරු බෆර භාවිතා කරන අතර දත්ත හැඹිලි කළමනාකරණය මෙහෙයුම් පද්ධතියට තබයි.

සමස්තයක් වශයෙන් මම බොහෝ අරමුණු සඳහා InnoDB සහ විශේෂිත භාවිතයන් සඳහා පමණක් MyISAM නිර්දේශ කරමි. InnoDB දැන් නව MySQL අනුවාද වල පෙරනිමි එන්ජිම වේ.


2
fwiw, InnoDB හි VARCHAR හට BLOB සහ TEXT වැනි පිටාර ගැලීම් පිටු වලටද යා හැකිය. මෙම සියලු දත්ත වර්ග අභ්‍යන්තරව ගබඩා කර ඇත.
බිල් කාර්වින්

දැන ගැනීම සතුටක්, ill බිල්කාර්වින්! අපගේ යෙදුමේ අපි VARCHAR අධික ලෙස භාවිතා කරන අතර VARCHAR මෙම k 8kB සීමාවට දායක වීම ටිකක් අදාළ වේ.
rinogo

වැඩි විස්තර සඳහා mysqlperformanceblog.com/2010/02/09/blob-storage-in-innodb බලන්න .
බිල් කාර්වින්

MySQL අනුවාදය 5.6+ හි innodb එන්ජිම ලෙස පිළිතුර යාවත්කාලීන නොවේ. වර්තමානයේදීද පූර්ණ පෙළ සුචිගත කිරීම් සඳහා සහය දක්වන අතර MySQL 5.5 + / 5.7 + අවකාශීය දත්ත වර්ග (5.5+) සහ අවකාශීය දර්ශක (r-tee) (5.7+) සඳහා සහය දක්වයි. .. හොඳම සහාය සඳහා ඔබට අවම වශයෙන් MySQL අනුවාදය 5.7+ තිබිය යුතුය
රේමන්ඩ් නිජ්ලන්ඩ්

25

ඔබ MyISAM භාවිතා කරන්නේ නම්, සෑම ඩීඑම්එල් ප්‍රකාශයක්ම ගනුදෙනුවක් ලෙස ඔබ සලකන්නේ නම් මිස, ඔබ පැයකට කිසිදු ගනුදෙනුවක් සිදු නොකරනු ඇත (එය කඩා වැටීමකදී කල් පවතින හෝ පරමාණුක නොවේ).

එබැවින් මම සිතන්නේ ඔබ InnoDB භාවිතා කළ යුතු බවයි.

තත්පරයට ගනුදෙනු 300 ක් සෑහෙන්න ගොඩක් වගේ. විදුලිය ඇණහිටීම හරහා මෙම ගනුදෙනු කල් පවත්නා වීමට ඔබට අවශ්‍ය නම්, ඔබේ I / O උප පද්ධතියට තත්පරයට බොහෝ ලිවීම් පහසුවෙන් හැසිරවිය හැකි බවට වග බලා ගන්න. ඔබට අවම වශයෙන් බැටරි පිටුබලය සහිත හැඹිලිය සහිත RAID පාලකයක් අවශ්‍ය වේ.

ඔබට කුඩා කල්පැවැත්මක් ලබා ගත හැකි නම්, ඔබට innoodb_flush_log_at_trx_commit 0 හෝ 2 ලෙස සකසා ඇති InnoDB භාවිතා කළ හැකිය (විස්තර සඳහා ලියකියවිලි බලන්න), ඔබට කාර්ය සාධනය වැඩි දියුණු කළ හැකිය.

ගූගල් සහ වෙනත් අයගෙන් සමගාමී මුදල් වැඩි කළ හැකි පැච් ගණනාවක් තිබේ - ඒවා නොමැතිව ඔබට තවමත් ප්‍රමාණවත් කාර්ය සාධනයක් ලබා ගත නොහැකි නම් මේවා උනන්දු විය හැකිය.


24

ප්‍රශ්නය සහ බොහෝ පිළිතුරු යල්පැන ඇත .

ඔව්, එය පැරණි භාර්යාවන්ගේ කතාවකි, මයිසාම් ඉනෝ ඩීබී වලට වඩා වේගවත්ය. ප්රශ්නයේ දිනය සැලකිල්ලට ගන්න: 2008; එය දැන් දශකයකට පමණ පසුව ය. InnoDB එතැන් සිට සැලකිය යුතු කාර්ය සාධනයක් ලබා ඇත.

: අනපේක්ෂිත ප්රස්තාරය MyISAM ජය එහිදී එක් නඩුව සඳහා වූ COUNT(*) තොරව එය WHEREවගන්තිය. නමුත් ඇත්තටම ඔබ ඔබේ කාලය ගත කරන්නේ එයද?

ඔබ සතුව සමගාමී පරීක්ෂණ, InnoDB, දිනා ගැනීමට ඉතා ඉඩ ඇත එරෙහිව පවාMEMORY .

මිණුම් සලකුණු කිරීමේදී ඔබ කිසියම් SELECTsලිවීමක් කළහොත්, MyISAM සහ MEMORYවගු මට්ටමේ අගුලු දැමීම නිසා අහිමි වීමට ඉඩ ඇත.

ඇත්ත වශයෙන්ම, ඔරකල්ට විශ්වාසයි InnoDB වඩා හොඳ ඒවා සියල්ලම මයිසෑම් 8.0 සිට ඉවත් කර ඇති බව.

මෙම ප්රශ්නය 5.1 දින තුළ මුල් ලියන ලදි. එතැන් සිට, මෙම ප්‍රධාන අනුවාදයන් "සාමාන්‍ය උපයෝජ්‍යතාව" ලෙස සලකුණු කරන ලදී:

  • 2010: 5.5 (දෙසැ .8 දී)
  • 2013: 5.6 (පෙබරවාරි මාසයේ 10)
  • 2015: 5.7 (ඔක් .9 දී)
  • 2018: 8.0 (.11 අප්‍රේල්)

නිගමනය: MyISAM භාවිතා නොකරන්න


3
MySQL දත්ත සමුදා තාක්ෂණ දියුණුව. තවද StackOverflow ප්‍රශ්නය සහ පිළිතුරු අතීතයේ දී ගිලී පවතී. MyISAM සහ InnoDB අතර ඇති ප්‍රධාන වෙනස්කම් සේවාදායකයේ "පැටවීම" ගැන අඩුය , සහ වැඩි සහයෝගය ගැන referential අඛණ්ඩතාව සහ ගනුදෙනු මෙන්ම, සමගාමී හා recoverability (+10)
spencer7593

12

MySQL සඳහාම ආදේශන කිහිපයක් බලන්න:

මාරියා ඩී බී

http://mariadb.org/

මාරියා ඩීබී යනු MySQL සඳහා ප්‍රතිස්ථාපන ක්‍රියාකාරිත්වය ලබා දෙන දත්ත සමුදා සේවාදායකයකි. මාරියා ඩීබී ගොඩනඟා ඇත්තේ නිදහස් හා විවෘත මෘදුකාංග සංවර්ධකයින්ගේ පුළුල් ප්‍රජාවේ සහාය ඇතිව MySQL හි මුල් කතුවරුන් විසිනි. MySQL හි මූලික ක්‍රියාකාරිත්වයට අමතරව, මාරියා ඩීබී විසින් විකල්ප ගබඩා එන්ජින්, සේවාදායක ප්‍රශස්තිකරණය සහ පැච් ඇතුළු විශේෂාංග වැඩි දියුණු කිරීම් මාලාවක් ඉදිරිපත් කරයි.

පර්කෝනා සේවාදායකය

https://launchpad.net/percona-server

වඩා හොඳ ක්‍රියාකාරිත්වය, වැඩිදියුණු කළ රෝග නිර්ණයන් සහ අමතර විශේෂාංග සහිතව MySQL සඳහා වැඩි දියුණු කළ ප්‍රතිස්ථාපනයක්.


1
මම මේ දෙකම භාවිතා කරමි (නිෂ්පාදනයේ පර්කෝනා, කවුළු සංවර්ධනය පිළිබඳ මාරියා). ඒවා වේගයෙන් ක්‍රියාත්මක වන අතර පරිපූර්ණ ලෙස ක්‍රියා කරයි.
මෝෂේ එල්

4
මෙය ප්‍රශ්නයට පිළිතුරු සපයන්නේ නැත. මාරියා ඩීබී සහ පර්කෝනා යනු MySQL හි දෙබලක වන අතර InnoDB සහ MyISAM එන්ජින් ද භාවිතා කරයි.
dr_

12

මගේ විධිමත් අධ්‍යාපනය සහ අත්දැකීම් ඔරකල් සමඟ ඇති බව කරුණාවෙන් සලකන්න . MySQL සමඟ මගේ වැඩ කටයුතු මුළුමනින්ම පෞද්ගලික සහ මගේ කාලය මත සිදු වූවක් වන අතර, එබැවින් මම ඔරකල් සඳහා සත්‍ය නමුත් MySQL සඳහා සත්‍ය නොවන දේවල් පැවසුවහොත් මම සමාව ඉල්ලමි. පද්ධති දෙක බොහෝ දේ බෙදා ගන්නා අතර, සම්බන්ධතා න්‍යාය / වීජ ගණිතය එක හා සමාන වන අතර, සම්බන්ධතා දත්ත සමුදායන් තවමත් සම්බන්ධතා දත්ත සමුදායන් වේ, තවමත් වෙනස්කම් රාශියක් ඇත !!

InnoDB ගනුදෙනු මත පදනම් වූවක් බව මම විශේෂයෙන් කැමතියි (පේළි මට්ටමේ අගුලු දැමීම), එයින් අදහස් වන්නේ ඔබ ඔබේ වෙබ් යෙදුමේ එක් “මෙහෙයුමක්” සඳහා කිහිප වතාවක් යාවත්කාලීන කිරීම / ඇතුළත් කිරීම / නිර්මාණය කිරීම / වෙනස් කිරීම / අතහැර දැමීම යනාදියයි. පැන නගින ගැටළුව නම් , එම වෙනස්කම් / ක්‍රියාකාරකම් වලින් සමහරක් පමණක් කැපවීමෙන් අවසන් වන නමුත් අනෙක් ඒවා එසේ නොවන්නේ නම්, ඔබ බොහෝ විට (දත්ත සමුදායේ නිශ්චිත සැලසුම අනුව) පරස්පර දත්ත / ව්‍යුහයක් සහිත දත්ත සමුදායක් සමඟ අවසන් වනු ඇත.

සටහන: ඔරකල් සමඟ, නිර්මාණය / වෙනස් කිරීම / වැටීම ප්‍රකාශ "ඩීඩීඑල්" (දත්ත අර්ථ දැක්වීම) ප්‍රකාශ ලෙස හැඳින්වෙන අතර, ව්‍යංගයෙන් බැඳීමක් ඇති කරයි. "ඩීඑම්එල්" (දත්ත හැසිරවීම) ලෙස හැඳින්වෙන ප්‍රකාශ ඇතුළත් කිරීම / යාවත්කාලීන කිරීම / මකා දැමීම ස්වයංක්‍රීයව නොවේ , නමුත් ඩීඩීඑල්, ​​කැපවීම, හෝ පිටවීම / ඉවත්වීම සිදු කළ විට පමණි (නැතහොත් ඔබ ඔබේ සැසිය "ස්වයංක්‍රීයව කැපවීම" ලෙස සකසන්නේ නම් හෝ ඔබේ සේවාදායකයා ස්වයංක්‍රීයව කටයුතු කරන්නේ නම්). ඔරකල් සමඟ වැඩ කිරීමේදී ඒ පිළිබඳව දැනුවත් වීම අත්‍යවශ්‍ය වේ, නමුත් MySQL ප්‍රකාශන දෙක හසුරුවන්නේ කෙසේදැයි මට විශ්වාස නැත. මේ නිසා, MySQL වෙත පැමිණෙන විට මට මෙය විශ්වාස නැති බව පැහැදිලි කිරීමට අවශ්‍යයි; ඔරකල් සමඟ පමණි.

ගනුදෙනු පදනම් කරගත් එන්ජින් විශිෂ්ට වන විට උදාහරණයක්:

නොමිලේ සිදුවීමකට සහභාගී වීම සඳහා මම හෝ ඔබ වෙබ් පිටුවක සිටින බව කියමු. පද්ධතියේ එක් ප්‍රධාන අරමුණක් වන්නේ 100 දෙනෙකුට පමණක් ලියාපදිංචි වීමට ඉඩ දීමයි. උත්සවය සඳහා. ලියාපදිංචි වීම් 100 ක් වෙත ළඟා වූ පසු, අවම වශයෙන් අනෙක් ඒවා අවලංගු වන තුරු පද්ධතිය තවදුරටත් ලියාපදිංචි වීම අක්‍රීය කරනු ඇත.

මෙම අවස්ථාවේදී, අමුත්තන් සඳහා වගුවක් (නම, දුරකථන, විද්‍යුත් තැපෑල, ආදිය) සහ ලියාපදිංචි වී ඇති අමුත්තන් ගණන නිරීක්ෂණය කරන දෙවන වගුවක් තිබිය හැකිය. මේ අනුව අපට එක් "ගනුදෙනුවක්" සඳහා මෙහෙයුම් දෙකක් තිබේ. ආගන්තුක තොරතුරු GUESTS වගුවට එකතු කිරීමෙන් පසුව, සම්බන්ධතා නැතිවීමක් හෝ එකම බලපෑමක් ඇති දෝෂයක් ඇතැයි සිතමු. GUESTS වගුව යාවත්කාලීන කරන ලදි (ඇතුළු කරන ලදි), නමුත් "ලබා ගත හැකි ආසන" යාවත්කාලීන කිරීමට පෙර සම්බන්ධතාවය නැති විය.

දැන් අපට ආගන්තුක වගුවට ආගන්තුකයෙකු එකතු කර ඇත, නමුත් දැන් ඇති ආසන ගණන වැරදිය. (උදාහරණයක් ලෙස, එය ඇත්ත වශයෙන්ම 84 වන විට වටිනාකම 85 කි).

ඇත්ත වශයෙන්ම මෙය හැසිරවීමට බොහෝ ක්‍රම තිබේ, එනම් “අමුත්තන්ගේ වගුවේ පේළි 100 ක min ණ සංඛ්‍යාවක් සහිත ආසන සොයා ගැනීම” හෝ තොරතුරු ස්ථාවරදැයි පරීක්ෂා කරන සමහර කේත යනාදිය. නමුත් ගනුදෙනු පදනම් කරගත් දත්ත ගබඩාවක් සමඟ එවැනි InnoDB, එක්කෝ එන්ජින් සියලූම මෙහෙයුම් කැපවී සිටින, හෝ NONE ඔවුන් ය. මෙය බොහෝ අවස්ථාවන්හිදී ප්‍රයෝජනවත් විය හැකි නමුත්, මා කීවාක් මෙන්, එය ආරක්ෂිතව සිටීමට ඇති එකම මාර්ගය නොවේ, නැත (කෙසේ වෙතත්, හොඳ ක්‍රමයක් නම්, දත්ත සමුදාය විසින් හසුරුවනු ලැබේ, ක්‍රමලේඛකයා / පිටපත් රචකයා නොවේ).

“ගනුදෙනුව පදනම් කරගත්” යන්නෙන් මූලිකවම අදහස් වන්නේ මා යමක් මග හැරී ඇත්නම් මිස - එක්කෝ සමස්ත ගනුදෙනුව සාර්ථක විය යුතුය, නැතහොත් කිසිවක් වෙනස් නොවේ. මන්දයත් අර්ධ වෙනස්කම් පමණක් සිදු කිරීමෙන් සුළු අවුලක් ඇතිවිය හැකි බැවිනි. දත්ත සමුදාය, සමහර විට එය දූෂිත විය හැකිය ...

නමුත් මම එය තවත් වරක් කියමි, එය අවුලක් වළක්වා ගත හැකි එකම ක්‍රමය නොවේ. නමුත් එය එන්ජිම විසින්ම හසුරුවන එක් ක්‍රමයක් වන අතර, ඔබ කේතය / ස්ක්‍රිප්ට් වෙත යොමු වන්නේ "ගනුදෙනුව සාර්ථකද නැද්ද යන්න ගැන කරදර විය යුතු අතර, අතින් වෙනුවට මම කුමක් කළ යුතුද (නැවත උත්සාහ කිරීම වැනි)" දත්ත සමුදායෙන් පිටත සිට "අතින්" පරීක්ෂා කිරීම සඳහා කේත ලිවීම සහ එවැනි සිදුවීම් සඳහා තවත් බොහෝ වැඩ කිරීම.

අවසාන වශයෙන්, පේළි අගුළු එදිරිව වගු අගුළු දැමීම පිළිබඳ සටහනක්:

වියාචනය: MySQL සම්බන්ධයෙන් පහත සඳහන් සියල්ලෙහි මම වැරදියි, සහ උපකල්පිත / උදාහරණ තත්වයන් සොයා බැලිය යුතු කරුණු වේ, නමුත් හරියටම කුමක් දැයි මම වැරදියි MySQL සමඟ හේතුව දූෂණ හැකි ය. සාමාන්‍ය ක්‍රමලේඛනයේදී උදාහරණ ඉතා සැබෑ ය, එවැනි දේ වළක්වා ගැනීම සඳහා MySQL සතුව තවත් යාන්ත්‍රණ තිබුණත් ...

කොහොම උනත්, මම කොපමණ සම්බන්ධතා වරකට අවසර ඇති තර්ක කර ඇති අය සමඟ එකඟ දී තරමක් විශ්වාසයි කරන්නේ නැහැ වහලා තිබුණු මේසය වටා වැඩ. ඇත්ත වශයෙන්ම, බහු සම්බන්ධතා යනු වගුවක් අගුළු දැමීමේ සමස්ත ලක්ෂ්‍යයයි !! එම නිසා වෙනත් ක්‍රියාවලීන් / පරිශීලකයින් / යෙදුම් එකවර වෙනස්කම් කිරීමෙන් දත්ත සමුදාය දූෂණය කිරීමට නොහැකි වේ.

එකම පේළියක වැඩ කරන සම්බන්ධතා දෙකක් හෝ වැඩි ගණනක් ඔබට සැබවින්ම නරක දවසක් වන්නේ කෙසේද ?? එකම පේළියක එකම අගය යාවත්කාලීන කිරීමට අවශ්‍ය / අවශ්‍ය වන ක්‍රියාදාමයන් දෙකක් ඇතැයි සිතමු, පේළිය බස් චාරිකාවක වාර්තාවක් වන නිසාත්, සෑම ක්‍රියාවලියක්ම එකවරම “රයිඩර්ස්” හෝ “ලබා ගත හැකි_ ආසන” යාවත්කාලීන කිරීමට අවශ්‍ය බවත් කියමු. ක්ෂේත්‍රය "වත්මන් අගය සහ 1" ලෙස

පියවරෙන් පියවර මෙය උපකල්පිත ලෙස කරමු:

  1. ක්‍රියාවලිය එකක් වත්මන් අගය කියවයි, එය හිස් යැයි කියමු, මේ දක්වා '0'.
  2. ක්‍රියාවලිය දෙකෙහි වත්මන් අගය ද කියවන අතර එය තවමත් 0 වේ.
  3. ක්‍රියාවලිය 1 ලියන (වත්මන් + 1) 1 වේ.
  4. ක්‍රියාවලිය දෙක 2 විය යුතුය, නමුත් එය නව අගය ලිවීමට පෙර වත්මන් අගය කියවන බැවින් එයද 1 වගුවට ලියයි.

සම්බන්ධතා දෙකක් ඒ හා සමාන විය හැකි බව මට විශ්වාස නැත , පළමු ලිවීමට පෙර කියවීම දෙකම ... නමුත් එසේ නොවේ නම්, මම තවමත් ගැටලුවක් දකිමි:

  1. ක්‍රියාවලිය එකක් වත්මන් අගය කියවන අතර එය 0 වේ.
  2. ක්‍රියාවලිය 1 ලිවීම (වත්මන් + 1), එය 1 වේ.
  3. ක්‍රියාවලිය දෙකෙහි වත්මන් අගය දැන් කියවයි. නමුත් එක් ඩීඅයිඩී ලිවීමක් (යාවත්කාලීන කිරීම) ක්‍රියාවට නංවන අතර, එය දත්ත සිදු කර නොමැති අතර, එමඟින් එම ක්‍රියාවලියට පමණක් එය යාවත්කාලීන කළ නව අගය කියවිය හැකි අතර අනෙක් සියල්ලම පැරණි අගය දකිනු ඇත.

එසේම, අවම වශයෙන් ඔරකල් දත්ත සමුදායන් සමඟ, හුදකලා මට්ටම් ඇත, ඒවා පරාමිතිකරණය කිරීමට අපේ කාලය නාස්ති නොකරමි. මෙන්න එම විෂය පිළිබඳ හොඳ ලිපියක් වන අතර, එක් එක් හුදකලා මට්ටමට එහි වාසි සහ අවාසි ඇති අතර, එමඟින් දත්ත සමුදායක් තුළ ගනුදෙනු පදනම් කරගත් එන්ජින් කෙතරම් වැදගත් විය හැකිද යන්නත් සමඟ ...

අවසාන වශයෙන්, විදේශීය යතුරු සහ ගනුදෙනු පදනම් කරගත් අන්තර්ක්‍රියා වෙනුවට MyISAM තුළ විවිධ ආරක්ෂණ තිබිය හැකිය. හොඳයි, එකක් සඳහා, මුළු වගුවක්ම අගුළු දමා ඇති අතර, එමඟින් ගනුදෙනු / එෆ්කේ අවශ්‍ය වේ.

අහෝ, ඔබ මෙම සමගාමී ගැටළු පිළිබඳව දැනුවත්ව සිටී නම්, ඔව් ඔබට එය අඩු ආරක්ෂිතව වාදනය කළ හැකි අතර ඔබේ අයදුම්පත් ලිවිය හැකිය, එවැනි දෝෂ ඇති නොවන පරිදි ඔබේ පද්ධති සකසන්න (ඔබේ කේතය වගකිව යුත්තේ දත්ත ගබඩාවට වඩා). කෙසේ වෙතත්, මගේ මතය අනුව, සෑම විටම හැකි තරම් ආරක්‍ෂිත ක්‍රම භාවිතා කිරීම, ආරක්ෂිතව වැඩසටහන්ගත කිරීම සහ මානව දෝෂය සම්පූර්ණයෙන් වළක්වා ගත නොහැකි බව සැමවිටම දැන සිටීම සුදුසු යැයි මම කියමි. එය සෑම කෙනෙකුටම සිදු වන අතර, ඔවුන් එයට ප්‍රතිශක්තියක් ඇති බව පවසන ඕනෑම කෙනෙක් බොරු කීම හෝ "හෙලෝ වර්ල්ඩ්" යෙදුමක් / පිටපතක් ලිවීමට වඩා වැඩි යමක් කර නැත. ;-)

එයින් සමහරක් යම්කිසි කෙනෙකුට ප්‍රයෝජනවත් වේ යැයි මම බලාපොරොත්තු වෙමි, ඊටත් වඩා, මම දැන් උපකල්පනවල වැරදිකරුවෙකු නොව වැරැදි මිනිසෙකු නොවෙමි යැයි මම බලාපොරොත්තු වෙමි !! එසේ නම් මගේ සමාව ඉල්ලන්න, නමුත් මෙම නිශ්චිත සන්දර්භය තුළ විභවයන් නොමැති වුවද, උදාහරණ ගැන සිතීම, අවදානම පිළිබඳ පර්යේෂණ කිරීම සහ යනාදිය හොඳයි.

මාව නිවැරදි කිරීමට නිදහස් වන්න, මෙම "පිළිතුර" සංස්කරණය කරන්න, එය ඡන්දය දෙන්න. කරුණාකර මගේ නරක උපකල්පනය වෙනත් දෙයක් සමඟ නිවැරදි කරනවාට වඩා වැඩිදියුණු කිරීමට උත්සාහ කරන්න. ;-)

මෙය මගේ පළමු ප්‍රතිචාරයයි, එබැවින් කරුණාකර සියලු වියාචනයන් නිසා දිගට සමාව දෙන්න ... මට නිශ්චිතවම විශ්වාස නැති විට අහංකාර ලෙස කතා කිරීමට මට අවශ්‍ය නැත!



5

මගේ අත්දැකීම් අනුව, ඔබ මකාදැමීම්, යාවත්කාලීන කිරීම්, තනි INSERT, ගනුදෙනු සහ පූර්ණ-පෙළ සුචිගත කිරීම් නොකරන තාක් කල් MyISAM වඩා හොඳ තේරීමක් විය. BTW, CHECK TABLE භයානකයි. පේළි ගණන අනුව වගුව වයස්ගත වන විට, එය අවසන් වන්නේ කවදාදැයි ඔබ නොදනී.


2
පූර්ණ-පෙළ සුචිගත කිරීම කළ හැක්කේ InnoDB සමඟ නොව MyISAM සමඟ පමණි.
පික්සල් අලියා

2
IxPixelElephant, එය MySQL 5.6 හි වෙනස් වීමට පටන් ගනී. InnoDB සතුව සම්පූර්ණ පෙළ දර්ශක වර්ගයක් ඇත, නමුත් මෙතෙක් එය IMHO නිෂ්පාදන භාවිතය සඳහා සූදානම් නැත.
බිල් කාර්වින්

1
“පූර්ණ-පෙළ සුචිගත කිරීම කළ හැක්කේ InnoDB සමඟ නොව MyISAM සමඟ පමණි”: MySQL> = 5.6 සිට තවදුරටත් සත්‍ය නොවේ. Dev.mysql.com/doc/refman/5.6/en/fulltext-search.html බලන්න .
හිබු 57

5

මයිසාම්ට අගුලු දැමීමේ මතභේද තිබුණද, එය බොහෝ අවස්ථාවන්හිදී ඉනෝ ඩීබී වලට වඩා වේගවත් බව මම තේරුම් ගතිමි. මම ඉනොඩ්බ් කිහිප වතාවක් උත්සාහ කර ඇති අතර සෑම විටම එක් හේතුවක් හෝ වෙනත් හේතුවක් නිසා නැවත මයිසෑම් වෙත වැටෙමි. එසේම InnoDB විශාල ලිවීමේ බරකින් ඉතා CPU තීව්‍ර විය හැකිය.


4

සෑම යෙදුමකටම දත්ත සමුදායක් භාවිතා කිරීම සඳහා තමන්ගේම කාර්ය සාධන පැතිකඩක් ඇති අතර කාලයත් සමඟ එය වෙනස් වීමට ඉඩ තිබේ.

ඔබට කළ හැකි හොඳම දේ ඔබේ විකල්පයන් පරීක්ෂා කිරීමයි. MyISAM සහ InnoDB අතර මාරුවීම ඉතා සුළුය, එබැවින් ඔබේ වෙබ් අඩවියට එරෙහිව පරීක්ෂණ දත්ත සහ ගිනි ජිමීටරයක් ​​පටවා සිදුවන්නේ කුමක්දැයි බලන්න.


4

අහඹු දත්ත MyISAM සහ InnoDB වගු වලට ඇතුළත් කිරීමට මම උත්සාහ කළෙමි. ප්රති result ලය තරමක් කම්පනයකි. InnoDB ට වඩා පේළි මිලියනයක් ඇතුළත් කිරීමට MyISAM ට තත්පර කිහිපයක් අඩු විය.


2
ඔබ ගනුදෙනුවක් භාවිතා කර InnoDB එන්ජිම සඳහා ස්වයංක්‍රීය සම්මුතිය අක්‍රිය කළහොත් ඔබට එකම කාර්ය සාධනය ලැබෙනු ඇත.
stanleyxu2005

එකම කාර්ය සාධනය නම් IDK, නමුත් එය වඩාත් සංකීර්ණ යෙදුම්වල මම කරන්නේ එය වේගවත් කරයි.
user965748

1
ඔබගේ අත්හදා බැලීමේ නිශ්චිත තොරතුරු සැපයීමට ඔබ අපොහොසත් විය - කුමන වින්‍යාස සැකසුම්? මීට පෙර වගුවේ (ය) තිබුණේ කුමක්ද? මොන වගේ දත්තද? සහ වඩාත්ම වැදගත් දෙය - අනුක්‍රමික ඇතුළත් කිරීම් තිබේද? සමාන්තරද? ඔවුන්ගේ වේලාව කුමක්ද? CPU කෝර් කීයක් තිබේද? නූල්? etc.
einpoklum

3

myisam යනු එම ආකාරයේ වැඩ බරක් සඳහා වන NOGO එකකි (ඉහළ සමගාමී ලියවිලි), මට ඉනොඩ්බ් සමඟ එතරම් අත්දැකීම් නොමැත (එය 3 වතාවක් පරීක්‍ෂා කර ඇති අතර සෑම අවස්ථාවකම කාර්ය සාධනය උරා ගත් බව සොයා ගන්නා ලදී, නමුත් අවසාන පරීක්ෂණයෙන් ටික කලක් ගතවී ඇත) ඔබ නම් mysql ධාවනය කිරීමට බල නොකෙරේ, සමගාමී ලියවිලි හසුරුවන විට පෝස්ට්ග්‍රෙස් උත්සාහ කර බලන්න.


3

කෙටියෙන් කිවහොත්, ඔබ විශ්වාසදායක දත්ත සමුදායක් අවශ්‍ය දෙයක් මත වැඩ කරන්නේ නම් InSDT සහ UPDATE උපදෙස් රාශියක් හැසිරවිය හැක.

මේස අගුලු දැමීමේ කාරණයෙහි ඇති අඩුපාඩුව සැලකිල්ලට ගනිමින් ඔබට ලිවීමට (INSERT සහ UPDATES) වඩා බොහෝ කියවීම් (SELECT) උපදෙස් ලබා ගත හැකි දත්ත සමුදායක් අවශ්‍ය නම් MyISAM හොඳයි.

ඔබට පරීක්ෂා කිරීමට අවශ්‍ය විය හැකිය;
InnoDB හි
වාසි සහ අවාසි MyISAM හි වාසි සහ අවාසි


2

මෙය ජනප්‍රිය නොවන බව මම දනිමි.

ගනුදෙනු සහ යොමු කිරීමේ අඛණ්ඩතාව වැනි දත්ත සමුදායන් සඳහා myISAM හි සහය නොමැති අතර එය බොහෝ විට දෝෂ සහිත / දෝෂ සහිත යෙදුම් වලට හේතු වේ. ඔබේ ඩීබී එන්ජිමෙන් පවා සහය නොදක්වන්නේ නම් ඔබට නිසි දත්ත සමුදා සැලසුම් මූලධර්ම ඉගෙන ගත නොහැක.

දත්ත සමුදා ලෝකයේ විමර්ශන අඛණ්ඩතාව හෝ ගනුදෙනු භාවිතා නොකිරීම හරියට මෘදුකාංග ලෝකයේ වස්තු නැඹුරු වැඩසටහන් භාවිතා නොකිරීම හා සමානයි.

InnoDB දැන් පවතී, ඒ වෙනුවට එය භාවිතා කරන්න! MySQL සංවර්ධකයින් පවා අවසාන වශයෙන් මෙය නව සංස්කරණ වල පෙරනිමි එන්ජිම ලෙස වෙනස් කිරීමට එකඟ වී ඇත, මයිසෑම් සියලු පැරණි පද්ධතිවල පෙරනිමිය වූ මුල් එන්ජිම වුවද.

නැත, ඔබ කියවන විට හෝ ලිවීමේදී හෝ ඔබ සතුව ඇති කාර්ය සාධන සලකා බැලීම්වල කිසිදු ගැටළුවක් නැත, myISAM භාවිතා කිරීම නිසා විවිධාකාර ගැටළු ඇති විය හැකිය, එනම් මම මේ මොහොතේ පැන ගිය කාරණය: මම දත්ත සමුදා සමමුහුර්ත කිරීමක් සිදු කළ අතර ඒ සමඟම වෙනත් අයෙක් myISAM වෙත සැකසූ වගුවකට ප්‍රවේශ වූ යෙදුමකට ප්‍රවේශ විය. ගනුදෙනු සහාය නොමැතිකම සහ මෙම එන්ජිමේ පොදුවේ දුර්වල විශ්වසනීයත්වය හේතුවෙන්, මෙය සමස්ත දත්ත ගබඩාවම බිඳ වැටුණු අතර මට mysql අතින් නැවත ආරම්භ කිරීමට සිදුවිය!

පසුගිය අවුරුදු 15 ක සංවර්ධනය තුළ මම බොහෝ දත්ත සමුදායන් සහ එන්ජින් භාවිතා කර ඇත. මෙම කාල පරිච්ෙඡ්දය තුළ myISAM දුසිමක් පමණ මා මතට ​​කඩා වැටුණි, වෙනත් දත්ත සමුදායන්, එක් වරක් පමණි! එය මයික්‍රොසොෆ්ට් SQL දත්ත සමුදායක් වන අතර සමහර සංවර්ධකයින් විසින් වැරදි සීඑල්ආර් කේතයක් ලියා ඇත (පොදු භාෂා ධාවන කාලය - මූලික වශයෙන් දත්ත සමුදාය තුළ ක්‍රියාත්මක වන සී # කේතය), එය හරියටම දත්ත සමුදා එන්ජිමේ වරදක් නොවේ.

ගුණාත්මක ඉහළ උපයෝජ්‍යතාවයකින් යුත්, ඉහළ කාර්යසාධනයක් සහිත යෙදුම් MyISAM භාවිතා නොකරන බැවින් එය ක්‍රියා නොකරනු ඇති බවත්, බලාපොරොත්තු සුන්වීමකින් තොර අත්දැකීමක් ලබා ගැනීමට එය ශක්තිමත් හෝ ස්ථාවර නොවන බවත් පවසන අනෙක් පිළිතුරු සමඟ මම එකඟ වෙමි .වැඩි විස්තර සඳහා බිල් කාර්වින්ගේ පිළිතුර බලන්න.

MyISAM රසිකයින් පහත් කොට සලකන විට PS ගොටා එයට ප්‍රිය කරයි, නමුත් මෙම පිළිතුරේ කුමන කොටස වැරදියි කියා ඔබට කිව නොහැක.


5
මම පහත් කොට සැලකුවේ නැත, නමුත් මම එසේ කළහොත් එය කිසි විටෙකත් භාවිතා නොකරන ලෙස උපදෙස් දීම සඳහා වේ. සංවර්ධකයාගේ වචන මාලාවේ කිසි විටෙකත් වචනය බිඳ දැමිය යුතු නැත ... අවවාද කිරීම 'කිසි විටෙකත් නොකියන්න'.
හබ්සන් බ්‍රෝපා

1

කියවීමේ / ලිවීමේ එම අනුපාතය සඳහා InnoDB වඩා හොඳ කාර්ය සාධනයක් කරනු ඇතැයි මම සිතමි. අපිරිසිදු කියවීම් වලින් ඔබ හොඳ බැවින්, ඔබට (ඔබට දරාගත හැකි නම්) දාසයෙකුට අනුරූපණය කර ඔබේ කියවීම් සියල්ල දාසයා වෙත යාමට ඉඩ දිය හැකිය. වරකට එක් වාර්තාවකට වඩා තොග වශයෙන් ඇතුළත් කිරීම සලකා බලන්න.


1

මම නව ව්‍යාපෘතියක් ආරම්භ කරන සෑම අවස්ථාවකම පාහේ මම ගූගල් විසින්ම මෙම ප්‍රශ්නයම පිළිතුරු සපයන්නේ දැයි බැලීමට.

එය අවසානයේදී පහතට තල්ලු වේ - මම MySQL හි නවතම අනුවාදය ගෙන පරීක්ෂණ ක්‍රියාත්මක කරමි.

මට යතුරු / අගය සොයා බැලීමට අවශ්‍ය වගු මා සතුව ඇත ... එපමණයි. මට හැෂ් යතුරක් සඳහා අගය (බයිට් 0-512) ලබා ගත යුතුය. මෙම ඩීබී හි ගනුදෙනු විශාල ප්‍රමාණයක් නොමැත. වගුවට ඉඳහිට යාවත්කාලීනයන් ලැබේ (සම්පුර්ණයෙන්ම), නමුත් ගනුදෙනු 0 ක්.

එබැවින් අපි මෙහි සංකීර්ණ පද්ධතියක් ගැන කතා නොකරමු, අපි කතා කරන්නේ සරල සොයා බැලීමක් ගැන ය .. සහ (මේස RAM පදිංචිය බවට පත් කිරීම හැර) අපට කාර්ය සාධනය ප්‍රශස්ත කළ හැක්කේ කෙසේද.

මට වාසියක් ලබා ගත හැකි කොතැනක හෝ තිබේදැයි බැලීමට මම වෙනත් දත්ත සමුදායන් (එනම් NoSQL) පරීක්ෂා කරමි. මා සොයාගෙන ඇති ලොකුම වාසිය යතුරු සිතියම්ගත කිරීමකි, නමුත් සොයා බැලීමේදී, මයිසාම් මේ සියල්ලටම වඩා ඉහළින් සිටී.

කෙසේ වෙතත්, මම MyISAM වගු සමඟ මූල්‍ය ගනුදෙනු නොකරමි, නමුත් සරල සොයා බැලීම් සඳහා, ඔබ එය පරීක්ෂා කර බැලිය යුතුය .. සාමාන්‍යයෙන් විමසුම් / තත්පර 2x සිට 5x දක්වා.

එය පරීක්ෂා කරන්න, මම විවාදය සාදරයෙන් පිළිගනිමි.


1

එය 70% ඇතුළු කිරීම් සහ 30% කියවීම් නම් එය InnoDB පැත්තේ වැඩිය.


0

නිගමනය: ඔබ විශාල දත්ත කැබලි තෝරාගැනීම් සමඟ නොබැඳි ලෙස වැඩ කරන්නේ නම්, MyISAM ඔබට වඩා හොඳ (වඩා හොඳ) වේගයක් ලබා දෙනු ඇත.

InnoDB ට වඩා MyISAM අසීමිත ලෙස කාර්යක්ෂම වන විට සමහර අවස්ථා තිබේ: විශාල දත්ත ඩම්ප්ලි නොබැඳි ලෙස හැසිරවීමේදී (මේස අගුල නිසා).

උදාහරණය: මම NOAA වෙතින් csv ගොනුවක් (15M වාර්තා) පරිවර්තනය කරමින් VARCHAR ක්ෂේත්‍ර යතුරු ලෙස භාවිතා කරමි. විශාල මතක කොටස් තිබියදීත් InnoDB සදහටම ගත විය.

මෙය csv සඳහා උදාහරණයකි (පළමු හා තෙවන ක්ෂේත්‍ර යතුරු වේ).

USC00178998,20130101,TMAX,-22,,,7,0700
USC00178998,20130101,TMIN,-117,,,7,0700
USC00178998,20130101,TOBS,-28,,,7,0700
USC00178998,20130101,PRCP,0,T,,7,0700
USC00178998,20130101,SNOW,0,T,,7,

මා කළ යුත්තේ නිරීක්‍ෂණය කරන ලද කාලගුණ සංසිද්ධිවල නොබැඳි යාවත්කාලීනයක් ධාවනය කිරීම නිසා, මම දත්ත ලබා ගැනීම සඳහා MyISAM වගුව භාවිතා කර යතුරු මත JOINS ධාවනය කරමි, එවිට මට එන ගොනුව පිරිසිදු කර VARCHAR ක්ෂේත්‍ර වෙනුවට INT යතුරු ආදේශ කළ හැකිය (ඒවා සම්බන්ධ) මුල් VARCHAR අගයන් ගබඩා කර ඇති බාහිර වගු).

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.