MySQL: විශාල VARCHAR එදිරිව TEXT?

852

මට MySQL හි පණිවිඩ වගුවක් ඇත, එය පරිශීලකයින් අතර පණිවිඩ වාර්තා කරයි. සාමාන්‍ය අයිඩී සහ පණිවිඩ වර්ග හැරුණු විට (සියලු පූර්ණ සංඛ්‍යා වර්ග) සත්‍ය පණිවිඩ පෙළ VARCHAR හෝ TEXT ලෙස සුරැකීමට මට අවශ්‍යය. මම අක්ෂර 3000 ක ඉදිරිපස සීමාවක් නියම කරමි, එයින් අදහස් කරන්නේ මෙයට වඩා දිගු කාලයක් පණිවිඩ db තුළට ඇතුළු නොවන බවයි.

VARCHAR (3000) හෝ TEXT සමඟ යෑමට තර්කයක් තිබේද? VARCHAR (3000) ලිවීම ගැන යමක් තිබේ, එය තරමක් ප්‍රති-බුද්ධිමත් බවක් දැනේ. මම Stack Overflow හි වෙනත් සමාන පෝස්ට් හරහා ගොස් ඇති නමුත් මෙම වර්ගයේ පොදු පණිවිඩ ගබඩා කිරීම සඳහා විශේෂිත අදහස් ලබා ගැනීම හොඳය.

mysql  text  messages  varchar 
— ටොම්
source
30
ටිකක් පරණයි, නමුත් මම මෙහි ආවේ මට මේ ගැන සිතීමට හේතු වූ ගැටලුවකට මුහුණ දුන් නිසාය. මගේ නඩුවේදී මගේ ඉදිරිපස ස්වරූපය අක්ෂර 2,000 කට සීමා වූ නමුත් මගේ ගබඩා ක්‍රමයේ ගම්‍ය වන අන්තර්ජාතික අක්ෂර බහු අක්ෂර ලෙස සංකේතවත් කර ඇත (පෙනෙන පරිදි අක්ෂරයකට 3 සිට 12 දක්වා ඕනෑම තැනක). ඉතින් මගේ 2,000 හදිසියේම 24,000 දක්වා ඉහළ යයි. සිතා බැලිය යුතු දෙයක් ...
— ජේම්ස් එස්
3
සමගාමී ඇතුළු කිරීම් බොහොමයකට පෙළ සැලකිය යුතු තරම් වේගවත් බව මම සොයාගෙන ඇත.
— රේ එස්.
1
@ ජේම්ස්: utf8mb4 ...>. <
— නොහැකි
10
Ick රික් ජේම්ස් ප්‍රශ්නය වසා දැමීමට වඩා යාවත්කාලීන පිළිතුරක් පළ කිරීම ගැන සලකා බලයි
3
@YvetteColomb - මම පිළිතුරක් එක් කළෙමි. මම, ඒ නිසා, ප්රධාන වශයෙන් වැනි පිළිගත් පිළිතුර මිදෙන්නට බව දිනය එළියට . මම ප්‍රශ්නෝත්තරයට පැමිණියේ යමෙකු වැරදි තොරතුරු උපුටා දක්වමින් "උඩු යටිකුරු 754 ක්, එබැවින් එය නිවැරදි විය යුතුය" යනුවෙනි. හරි, මම අනුමත කළ පිළිතුරද සංස්කරණය කළෙමි. (එය නුසුදුසු යැයි හැඟුනත්.)
— රික් ජේම්ස්

Answers:

816

  • TEXTහා BLOB විය හැක විසින් පමණක් සත්ය ගබඩා ඇති ස්ථානය වෙත අවධානය යොමුකළ සහිත මේසය සමඟ කෑමට ලකුණු ගබඩා. එය ගබඩා කර ඇති ස්ථානය දත්ත ප්‍රමාණය, තීරු ප්‍රමාණය, පේළි_ ආකෘතිය, සහ MySQL අනුවාදය වැනි බොහෝ දේ මත රඳා පවතී.

  • VARCHARවගුව සමඟ පේළියේ ගබඩා කර ඇත. VARCHARප්‍රමාණය සාධාරණ වන විට වේගවත් වන අතර, වෙළඳාම වේගවත් වනු ඇත්තේ ඔබේ දත්ත සහ දෘඩාංග මත ය, ඔබේ දත්ත සමඟ සැබෑ ලෝක තත්වයක් මිණුම් සලකුණු කිරීමට ඔබට අවශ්‍යය.

— MindStalker
source
150
+1: දත්ත නිතර ලබා ගන්නේ නම් (බොහෝ විමසුම් වලට ඇතුළත් වේ) VARCHAR (පේළිගතව ගබඩා කර ඇත) සාමාන්‍යයෙන් වේගවත් වේ. කෙසේ වෙතත්, සාමාන්‍යයෙන් ලබා නොගත් විශාල දත්ත ප්‍රමාණයක් සඳහා (එනම්, කිසිදු විමසුමකින් යොමු නොකෙරේ), එවිට දත්ත පේළියේ ගබඩා නොකිරීම වඩා හොඳ විය හැකිය. පේළි ප්‍රමාණයේ ඉහළ සීමාවක් ඇත, පේළිගතව ගබඩා කර ඇති දත්ත සඳහා.
— spencer7593
22
Ac පැසීරියර්: “පේළිගත” ගබඩා කිරීමෙන් වැළකීමේ නිශ්චිත වාසිය නම් බ්ලොක් එකක ගබඩා කළ හැකි පේළි ගණන වැඩි වීමයි, එයින් අදහස් වන්නේ මේස පේළි ඉනෝ ඩී බී බෆර් හැඹිලියේ (කුඩා මතක අඩිපාර) අඩු කොටස් ප්‍රමාණයක් ඇති බවත්, එයින් අදහස් කරන්නේ අඩු බවත්ය බ්ලොක් තැටියට හා ඉන් මාරු කළ යුතුය (අඩු කළ I / O). නමුත්, මෙය කාර්ය සාධන ප්‍රතිලාභයක් වන්නේ “පේළියෙන් බැහැර” තීරු බොහෝ දුරට විමසුම් මගින් යොමු නොකෙරේ නම් පමණි. එම “ඕෆ් පේළි” තීරු බොහෝ විමසුම් මගින් යොමු කරනු ලැබුවහොත්, එම ප්‍රතිලාභ බොහෝ දුරට වාෂ්ප වී යයි. තීරු උපරිම පේළි වලට ගැලපෙන අතර නිතර යොමු කරනු ලැබේ නම් පේළිය වඩාත් සුදුසු වේ.
— spencer7593
233
"ප්‍රමාණය සාධාරණ වන විට VARCHAR වේගවත් වේ". "සාධාරණ" අක්ෂර ගණන, 100 යනු කුමක්ද? 1000 ද? 100,000?
— ටයිම් පීටර්සන්
128
InnoDB සඳහා මෙම පිළිතුර නිවැරදි නොවේ. දී ඇති පේළියක වටිනාකම පිටු ප්‍රමාණයට ගැලපෙන්නේ නම් VARCHAR සහ BLOB / TEXT යන දෙකම වෙනත් තීරු සමඟ පේළිගතව ගබඩා කර ඇත (16KB සහ සෑම පිටුවකම අවම වශයෙන් පේළි දෙකක්වත් තිබිය යුතුය). ඒ සඳහා නූල ඉතා විශාල නම්, එය අතිරේක පිටු වලට පිරී යයි. සවිස්තරාත්මක පැහැදිලි කිරීමක් සඳහා mysqlperformanceblog.com/2010/02/09/blob-storage-in-innodb බලන්න .
— බිල් කාර්වින්
15
Ill බිල්කාර්වින් ... මම නිවැරදිව තේරුම් ගන්නේ නම් කුඩා පෙළ අයිතම සඳහා InnoDB varcharසහ blob/ අතර කාර්ය සාධන වෙනසක් නොතිබිය යුතුද text? ඒ නිසා එය එසේ නම් දැන් සෑම කිරීමට ප්රයෝජනවත් වෙයි varcharවූ textවර්ගය සහ ඩී.බී. මෙම පේළිගත එදිරිව පිටාර ගලා කළමනාකරණය ඉඩ?
— ryvantage
479

පරිශීලක ආදානය කොපමණ කාලයක් පවතිනු ඇත්දැයි ඔබට පුරෝකථනය කළ හැකිද?

වර්චාර් (එක්ස්)

නඩුව: පරිශීලක නාමය, විද්‍යුත් තැපෑල, රට, විෂය, මුරපදය

පෙළ

නඩුව: පණිවිඩ, ඊමේල්, අදහස්, ආකෘතිගත කළ පෙළ, html, කේතය, රූප, සබැඳි

මාධ්‍යය

නඩුව: විශාල ජේසන් සිරුරු, කෙටි සිට මධ්‍යම දිග පොත්, සීඑස්වී නූල්

දිග

නඩුව: පෙළපොත්, වැඩසටහන්, ලොග් ලිපිගොනු වසර, හැරී පොටර් සහ ගින්දර, විද්‍යාත්මක පර්යේෂණ ල ging ු-සටහන්

— මයිකල් ජේ. කැල්කින්ස්
source
8
පුරෝකථනය කිරීමේ හැකියාව සැබවින්ම මෙහි අතුරු අයිතමයකි. එය ඇත්ත වශයෙන්ම තීරණය කරන සාධකය විය යුතු උපරිම අපේක්ෂිත දිග වේ. ඔබ අනාවැකි කිව හැකි අයිතමයන් එසේ වන්නේ ඒවා අනෙක් ඒවාට වඩා කෙටි නිසාය .
— ඇන්ඩ rew බාබර්
30
@ ඇන්ඩ rew-බාබර් එය මගේ කාරණය වුවත්. අනෙක් සියලුම තනතුරු වෙනස්කම් ගැන හොඳින් පැහැදිලි කරයි, නමුත් ඇත්ත වශයෙන්ම ඔබ දෙදෙනා අතර තේරීමක් කළ යුතු අවස්ථා ගැන නොවේ. මම පෙන්වා දීමට උත්සාහ කළේ අනාවැකි කිව හැකි කෙටි සඳහා වර්චාර් භාවිතා කිරීම හොඳ තේරීමක් වන අතර අත්තනෝමතික ලෙස දිගු කාලයක් සඳහා පෙළ භාවිතා කිරීම හොඳ තේරීමක් වේ.
— මයිකල් ජේ. කැල්කින්ස්
1
සියලුම තීරු කෙටි හා පුරෝකථනය කළ හැකි නම් (උදා: MAC ලිපිනය, IMEI, ආදිය ... කිසි විටෙකත් වෙනස් නොවන දේවල් වේ) එවිට CHAR තීරු භාවිතා කරන්න, එවිට ඔබට ඔබේ පේළි ප්‍රමාණය ස්ථාවර කළ හැකිය, එමඟින් MyISAM භාවිතා කරන්නේ නම් දේවල් සැලකිය යුතු ලෙස වේගවත් කළ හැකිය. InnoDb ද මට ඒ ගැන විශ්වාස නැත.
— මතෙ
1
@ මයිකල් ජේ. කැල්කින්ස් MySQL 5.6 හි සිදු වූ දෙය. දැන් ඔබට InnoDB හි සම්පූර්ණ පා search සෙවීමක් ද ඇත. Dev.mysql.com/doc/refman/5.6/en/fulltext-search.html
— PhoneixS
7
චරිත සීමාවන්: TINYTEXT: 255; ටෙක්ස්ට්: 65,535; මාධ්‍ය: 16,777,215; දිග: 4,294,967,29.
— වික්ටර් ස්ටෝඩාර්ඩ්
219

හොඳම පුහුණුව පැහැදිලි කිරීම සඳහා:

  1. පෙළ ආකෘති පණිවිඩ සෑම විටම පාහේ TEXT ලෙස ගබඩා කළ යුතුය (ඒවා අත්තනෝමතික ලෙස දිගු වේ)

  2. සංගීත ගුණාංග VARCHAR ලෙස ගබඩා කළ යුතුය (ගමනාන්ත පරිශීලක නාමය, විෂය යනාදිය ...).

ඔබට ඉදිරිපස සීමාවක් ඇති බව මට වැටහී ඇත, එය එසේ නොවන තෙක් එය විශිෂ්ටයි. * සිනහව * උපක්‍රමය නම් ඩීබී එයට සම්බන්ධ වන යෙදුම් වලින් වෙන්ව සිතීමයි. එක් යෙදුමක් දත්ත සඳහා සීමාවක් පනවා ඇති පමණින්, දත්ත සහජයෙන්ම සීමිත බව එයින් අදහස් නොවේ.

අක්ෂර 3000 ට වඩා වැඩි වීමට කිසි විටෙකත් බල නොකරන පණිවිඩ ගැන කුමක් කිව හැකිද? එය අත්තනෝමතික යෙදුම් අවහිරයක් නම් (කියන්න, පෙළ කොටුවක් හෝ වෙනත් දෙයක් සඳහා), TEXTදත්ත ස්ථරයේ ක්ෂේත්‍රයක් භාවිතා කරන්න .

— ජේම්ස්
source
“එය විශිෂ්ට නොවන තෙක්” යන්නෙන් අදහස් කරන්නේ කුමක්ද? “නොකියන්නේ” යන්නෙන් අදහස් කරන්නේ කුමක්ද?
— පැසීරියර්
8
AcPacerier ඔබට “නැත” යන්න පිළිබඳ උදාහරණයක් ලබා දීමට ජේම්ස් බොහෝ දුරට ඉඩ ඇත: උදාහරණයක් ලෙස ට්විටර් ගන්න, මෑතක් වන තුරුම PMs සඳහා අක්ෂර 140 ක සීමාවක් තිබුණි. එය තවදුරටත් සංවේදී නොවන බව ඔවුන් තීරණය කළ අතර එම සීමාව සම්පූර්ණයෙන්ම ඉවත් කිරීමට තීරණය කළහ. ඔවුන් ඒ ගැන කලින් නොසිතුවේ නම් (ඔවුන් බොහෝ විට එසේ කර ඇති බව මට හොඳටම විශ්වාසයි ...) ඔවුන් ඉහත දක්වා ඇති තත්වයට දිව යනු ඇත.
— පෝල්ස්කින්නර්
9
මම දැන් අපගේ නව දත්ත සමුදාය සකස් කරමින් සිටිමි, අපගේ කුඩා විවරණ පෙට්ටිවලට අක්ෂර 2000 කට වඩා වැඩි ප්‍රමාණයක් කිසිවෙකුට තැබිය නොහැකි යැයි මම සිතුවෙමි, පසුව ජේම්ස් සටහන් කරන පරිදි, අද රාත්‍රියේ එය හදිසියේම "අවුලක් නැත" අක්ෂර 2600 ක් දිග ඉතා වලංගු අදහස් දැක්වීමකි. මම වර්චාර් (2000) භාවිතා කළේ ඊට වඩා වැඩි කාලයක් ලබා ගත නොහැකි යැයි සිතමිනි, මම වැරදිය. ඉතින් ඔව්, එය එසේ නොවන තුරු එය විශිෂ්ටයි. ප්‍රකාශ කිරීමට දින කිහිපයක් පමණක් ගත වූ අපගේ නඩුවේ. පහත දැක්වෙන රීතිය, මයිකල් ජේ. කැල්කින්ස්, මම හිතන්නේ මම මෙතැන් සිට භාවිතා කරනු ඇත. පණිවිඩ, අදහස් සඳහා පෙළ.
— Lizardx
1
Ac පැසීරියර් "එය විශිෂ්ට නොවන තෙක් විශිෂ්ටයි". වෙනත් වචන වලින් කිවහොත්, එය සෑම විටම පාහේ ක්‍රියාත්මක වන අතර එය අපූරුය ... එය එතරම් විශාල නොවන සුවිශේෂී අවස්ථා හැර.
— සීමිත පව් කමාව
Ac පැකේරියර් තෝරාගත් පිළිතුරේ අදහස් දැක්වීමේදී තවත් සිත්ගන්නාසුලු උදාහරණයක් සඳහන් කර ඇත, මූලික වශයෙන් ඔහුට ඉදිරිපස සීමාවන් 2000 ක් විය, නමුත් හඳුන්වා දුන් චරිත කේත පිටුවේ යථාර්ථයේ දී සාමාන්‍ය අක්ෂරවලට වඩා බයිට් වැඩි ප්‍රමාණයක් භාවිතා කළ අතර ඔහුගේ දත්ත ගබඩාවට අවකාශය අවශ්‍ය විය. අක්ෂර 24k සඳහා, හඳුන්වා දී ඇති අක්ෂරවල සත්‍ය බයිට් ප්‍රමාණය ඔහුට ගණන් ගත යුතුව තිබූ නිසාය.
— රැප්ටර්එක්ස්
32

වියාචනය: මම MySQL විශේෂ expert යෙක් නොවේ ... නමුත් මෙය ගැටළු පිළිබඳ මගේ අවබෝධයයි.

මම හිතන්නේ TEXT mysql පේළියෙන් පිටත ගබඩා කර ඇති අතර VARCHAR පේළියේ කොටසක් ලෙස ගබඩා කර ඇති බව මම සිතමි. MySQL පේළි සඳහා උපරිම පේළි දිගක් ඇත .. එබැවින් ඔබට VARCHAR භාවිතා කිරීමෙන් පේළියක ගබඩා කළ හැකි වෙනත් දත්ත සීමා කළ හැකිය.

VARCHAR පේළියේ කොටසක් සෑදීම නිසා, එම ක්ෂේත්‍රය දෙස බලන විමසුම් TEXT කැබැල්ලක් භාවිතා කරන අයට වඩා තරමක් වේගවත් වනු ඇතැයි මම සැක කරමි.

— මයිකල් ඇන්ඩර්සන්
source
38
පේළි දිග සීමාව බයිට් 65,535 [ dev.mysql.com/doc/refman/5.0/en/column-count-limit.html ] වේ. ඔබේ තීරුව utf8- කේතනය කර ඇත්නම්, එයින් අදහස් වන්නේ අක්ෂර 3000 ක varcharතීරුවකට බයිට් 9000 ක් ගත විය හැකි බවයි.
— Jan Fabry
7
UTF-8 අක්ෂර බයිට් 4 ක් දක්වා විය හැකිය, එබැවින් ඔබ අදහස් කළේ බයිට් 12,000 ක් යැයි මම සිතමි (සමහර MySQL දෙයක් නොමැති නම් මට මෙහි නොතේරේ).
— raylu
13
@raylu MySQL හි UTF-8 “ව්‍යාජ යූටීඑෆ් -8” වන අතර එය උපරිම වශයෙන් අනුබල දෙන්නේ බයිට් 3 ක් පමණි, එබැවින් බීඑම්පී තලය ඉක්මවා යුනිකෝඩ් අක්ෂර සෘජුවම MySQL හි UTF-8 තුළ ගබඩා කිරීමට ක්‍රමයක් නොමැත. මෙය MySQL 5.5 හි සවි කර ඇත.
— පැසීරියර්
2
මෙම ප්‍රකාශය වලංගු වන්නේ MyISAM සඳහා පමණක් බව මම විශ්වාස කරමි. මට නිශ්චිත ප්‍රභවයක් සොයාගත නොහැකි නමුත් InnoDB TEXTමේසය තුළ පේළිගතව ගබඩා කරන බව මම විශ්වාස කරමි .
— dotancohen
2
indotancohen InnoDB භාවිතා කරමින් විචල්‍ය දිග දත්ත ගබඩා කිරීම වෙනස් විය හැකි බව පැහැදිලි කරන මූලාශ්‍රයක් මට හමු විය (පේළිය තුළ බාහිරව හෝ පේළියේ ගබඩා කළ හැකිය) mysqlserverteam.com/externally-stored-fields-in-innodb
— KiX Ortillan
30

කෙටි පිළිතුර: ප්‍රායෝගික, ක්‍රියාකාරීත්වය හෝ ගබඩා කිරීම, වෙනසක් නැත.

දිගු පිළිතුර:

VARCHAR(3000)(හෝ වෙනත් විශාල සීමාවක්) සහ අතර වෙනසක් (MySQL හි) අත්‍යවශ්‍යයෙන්ම නොමැත TEXT. පළමුවැන්නා අක්ෂර 3000 කින් කපා දමනු ඇත ; දෙවැන්න බයිට් 65535 ට කපා දමනු ඇත . ( චරිතයකට බයිට් කිහිපයක් ගත හැකි නිසා මම බයිට් සහ අක්ෂර අතර වෙනසක් කරමි .)

තුළ ඇති කුඩා සීමාවන් සඳහා VARCHAR, වඩා වාසි කිහිපයක් ඇත TEXT.

  • “කුඩා” යන්නෙන් 191, 255, 512, 767, හෝ 3072 යනාදිය අනුවාදය, සන්දර්භය සහ CHARACTER SET.
  • INDEXesතීරුවක් කොතරම් විශාල ලෙස සුචිගත කළ හැකිද යන්න සීමා වේ. ( බයිට් 767 හෝ 3072 ; මෙය අනුවාදය සහ සැකසුම් මත රඳා පවතී)
  • සංකීර්ණය විසින් නිර්මාණය කරන ලද අතරමැදි වගු SELECTsවෙනස් ආකාර දෙකකින් හසුරුවනු ලැබේ - මතක (වේගවත්) හෝ මයිසාම් (මන්දගාමී). 'විශාල' තීරු සම්බන්ධ වූ විට, මන්දගාමී තාක්ෂණය ස්වයංක්‍රීයව තෝරා ගනු ලැබේ. (8.0 අනුවාදයේ සැලකිය යුතු වෙනස්කම් පැමිණේ; එබැවින් මෙම උණ්ඩ අයිතමය වෙනස් වීමට යටත් වේ.)
  • පෙර අයිතමයට TEXTසාපේක්ෂව , සියලු දත්ත වර්ග (ප්‍රතිවිරුද්ධව VARCHAR) කෙලින්ම MyISAM වෙත පනින්න. එනම්, TINYTEXTජනනය කරන ලද තාවකාලික වගු වලට සමාන ප්‍රමාණයට වඩා ස්වයංක්‍රීයව නරක ය VARCHAR. (නමුත් මෙය සාකච්ඡාව තුන්වන දිශාවට ගෙන යයි!)
  • VARBINARYවැනි ය VARCHAR; BLOBවගේ TEXT.

වෙනත් පිළිතුරු වෙත නැවත යොමු කිරීම

මුල් ප්‍රශ්නය එක් දෙයක් ඇසීය (කුමන දත්ත සමුදාය භාවිතා කළ යුතුද); පිළිගත් පිළිතුර වෙනත් දෙයකට පිළිතුරු සපයයි (වාර්තාගත නොවන ගබඩා කිරීම). එම පිළිතුර දැන් යල්පැන ඇත.

මෙම ත්‍රෙඩ් එක ආරම්භ කර පිළිතුරු දුන් විට, InnoDB හි තිබුණේ “පේළි ආකෘති” දෙකක් පමණි. වැඩි කල් යන්නට මත්තෙන් තවත් ආකෘති දෙකක් ( DYNAMICසහ COMPRESSED) හඳුන්වා දෙන ලදී.

ගබඩා කිරීමේ ස්ථානය TEXTසහ VARCHAR()ප්‍රමාණය මත පදනම් වේ , දත්ත සමුදායේ නම මත නොවේ . විශාල පෙළ / බ්ලොබ් තීරු මත / අක්‍රීයව ගබඩා කිරීම පිළිබඳ යාවත්කාලීන සාකච්ඡාවක් සඳහා මෙය බලන්න .

— රික් ජේම්ස්
source
2
Ost කොස්ටාකොන්ටොස් - ප්‍රශංසාවට සහ යතුරු ලියනය නිවැරදි කිරීමට ස්තූතියි. වඩා හොඳ පිළිතුරක් අවශ්‍ය බව මා දුටු විට, අවුරුදු 8 ක් සහ ඉහළ නැංවීම් 800 ක් ප්‍රමාද වුවද මම පිළිතුරක් එක් කරමි.
— රික් ජේම්ස්
7

පූර්ව පිළිතුරු ප්‍රධාන ගැටළුව සඳහා ප්‍රමාණවත් ලෙස අවධාරනය නොකරයි: වැනි ඉතා සරල විමසුම් වලදී පවා

(SELECT t2.* FROM t1, t2 WHERE t2.id = t1.id ORDER BY t1.id)

තාවකාලික වගුවක් අවශ්‍ය විය හැකි අතර, VARCHARක්ෂේත්‍රයක් සම්බන්ධ නම් එය CHARතාවකාලික වගුවේ ක්ෂේත්‍රයක් බවට පරිවර්තනය වේ . එබැවින් ඔබේ වගුවේ VARCHAR(65000)ක්ෂේත්‍රයක් සහිත පේළි 500 000 ක් තිබේ නම් , මෙම තීරුව පමණක් 6.5 * 5 * 10 ^ 9 බයිට් භාවිතා කරයි. එවැනි තාවකාලික වගු මතකයේ හැසිරවිය නොහැකි අතර ඒවා තැටියට ලියා ඇත. බලපෑම විනාශකාරී යැයි අපේක්ෂා කළ හැකිය.

මූලාශ්‍රය (ප්‍රමිතික සමඟ): https://nicj.net/mysql-text-vs-varchar-performance/ (මෙයින් අදහස් කරන්නේ “සම්මත” (?) MyISAM ගබඩා එන්ජිමෙහි TEXTඑදිරිව හැසිරවීමයි.එය VARCHARඅනෙක් ඒවා අතර වෙනස් විය හැකිය, උදා: InnoDB.)

— උපරිම
source
3
InnoDB: 5.7 අනුවාදය හරහා ද මෙය අදාළ වේ. 8.0 සමඟ, වර්චාර් ටෙම්ප්ස් විචල්ය දිග වේ.
— රික් ජේම්ස්
4

ඒ නිසා එය විශාල VARCHAR සහ පෙළ අතර වෙනස. VARCHAR ක්ෂේත්‍ර සුචිගත කළ හැකි නමුත් TEXT ක්ෂේත්‍රවලට නොහැක. VARCHAR වර්ගයේ ක්ෂේත්‍ර පේළිගතව ගබඩා කර ඇති අතර TEXT නොබැඳි ලෙස ගබඩා කර ඇත, TEXT දත්ත වෙත යොමු කරන්නන් පමණක් වාර්තා වල ගබඩා කර ඇත.

VARCHAR සඳහා යෑමට වඩා වේගවත් සෙවීම, යාවත්කාලීන කිරීම හෝ මකා දැමීම සඳහා ඔබේ ක්ෂේත්‍රය සුචිගත කිරීමට ඔබට සිදුවුවහොත්, කොතරම් විශාල වුවත්. VARCHAR (10000000) කිසි විටෙකත් TEXT ක්ෂේත්‍රය හා සමාන නොවේ. මෙම දත්ත වර්ග දෙක ස්වභාවයෙන්ම වෙනස් වේ.

  • ඔබ සංරක්‍ෂණය සඳහා පමණක් ක්ෂේත්‍රය භාවිතා කරන්නේ නම්
  • දත්ත වේගය නැවත ලබා ගැනීම ගැන ඔබ තැකීමක් නොකරයි
  • ඔබ වේගය ගැන සැලකිලිමත් වන නමුත් ඔබේ සෙවුම් විමසුමේදී '% LIKE%' ක්‍රියාකරු භාවිතා කරනු ඇත, එබැවින් සුචිගත කිරීම බොහෝ සෙයින් උපකාරී නොවේ
  • ඔබට දත්ත දිගෙහි සීමාවක් අනාවැකි කිව නොහැක

TEXT සඳහා යන්නට වඩා.

— වික්ටර් ජෝරාස්
source
අර්ධ වශයෙන් නොමඟ යවන තොරතුරු: TEXT තීරු සම්පුර්ණයෙන්ම දර්ශක විය නොහැක. ඔබ දර්ශකයේ TEXT තීරුවක් ඇතුළත් කළ විට ඔබ දිග නියම කළ යුතුය. දර්ශක ප්‍රමාණයෙහි උපරිම දිගක් ඇති බැවින් VARCHARs> 255 සම්බන්ධයෙන් VARCHARs සම්පුර්ණයෙන්ම සුචිගත කළ නොහැක.
— eRadical
3

වර්චාර් යනු ඊමේල් ලිපින වැනි කුඩා දත්ත සඳහා වන අතර, පෙළ යනු ප්‍රවෘත්ති ලිපි වැනි විශාල දත්ත සඳහා වන අතර, රූප වැනි ද්විමය දත්ත සඳහා බ්ලොබ් ය.

වර්චාර් හි ක්‍රියාකාරීත්වය වඩා බලවත් වන්නේ එය සම්පූර්ණයෙන්ම මතකයෙන් ධාවනය වන බැවිනි, නමුත් varchar(4000)උදාහරණයක් ලෙස දත්ත විශාල වුවහොත් එය එසේ නොවේ .

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

බ්ලොබ් වඩා මන්දගාමී බැවින් එය භාවිතා කරන්න ඔබට පින්තූර 10000 වැනි දත්ත නොමැති නම් පමණක් වාර්තා 10000 ක් වැය වේ.

උපරිම වේගය සහ ක්‍රියාකාරිත්වය සඳහා මෙම ඉඟි අනුගමනය කරන්න:

  1. නම, මාතෘකා, ඊමේල් සඳහා varchar භාවිතා කරන්න

  2. විශාල දත්ත සඳහා පෙළ භාවිතා කරන්න

  3. විවිධ වගු වල පෙළ වෙන් කරන්න

  4. දුරකථන අංකයක් වැනි හැඳුනුම්පතක වම් සම්බන්ධ විමසුම් භාවිතා කරන්න

  5. ඔබ බ්ලොබ් භාවිතා කිරීමට යන්නේ නම් පෙළෙහි ඇති ඉඟි යොදන්න

දත්ත> 10 එම් සහ ප්‍රමාණය 10GB දක්වා සහතික සහිත වගු මත විමසුම් සඳහා මිල මිලි තත්පර වේ.

— නිර්මාණාත්මක 87
source
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.