Utf8_general_ci සහ utf8_unicode_ci අතර වෙනස කුමක්ද?


1085

අතර utf8_general_ciසහ utf8_unicode_ci, කාර්ය සාධනය අනුව යම් වෙනසක් තිබේද?


1
මෙයද බලන්න stackoverflow.com/questions/1036454/...
unor

6
ඔබ කැමති නම් utf8[mb4]_unicode_ci, ඔබ ඊටත් වඩා කැමති විය හැකියutf8[mb4]_unicode_520_ci .
රික් ජේම්ස්

8
ඒ ගැන මට හැඟෙන්නේ කෙසේදැයි මම නොදනිමි - නවතම යුනිකෝඩ් ප්‍රමිතිය අනුගමනය කිරීම සඳහා ඒවා ක්‍රියාත්මක කිරීම වෙනුවට ඒවා යල් පැන ගිය අනුවාදය පෙරනිමිය ලෙස තබා ගන්නා අතර නිසි පරිදි භාවිතා කිරීමට මිනිසුන්ට "520" එකතු කළ යුතුය. පැරණි MySQL අනුවාද වල "520" අනුවාදය ඔබට භාවිතා කළ නොහැකි නිසා එය ඉදිරියට හා පසුපසට නොගැලපේ. ඔවුන්ගේ පවතින එකතුව යාවත්කාලීන කිරීමට ඔවුන්ට නොහැකි වූයේ ඇයි? "Mb4" හා සමානයි. පෙරනිමිය ලෙස තබා ගැනීම සාධාරණීකරණය කිරීම සඳහා පැරණි, සීමිත / යල්පැනගිය හැසිරීම මත සැබවින්ම රඳා පවතින කේතය කුමක්ද?
thomasrutter

7
8.0 හි පෙරනිමිය තවමත් හොඳය utf8mb4_0900_ai_ci.
රික් ජේම්ස්

Answers:


1620

මෙම සංයෝජන දෙක UTF-8 අක්ෂර කේතනය සඳහා වේ. වෙනස්කම් ඇත්තේ පෙළ වර්ග කර සංසන්දනය කරන ආකාරයයි.

සටහන: MySQL හි ඔබ භාවිතා utf8mb4කිරීමට වඩා භාවිතා කළ utf8යුතුය. අවුල් utf8සහගත ලෙස, මුල් MySQL අනුවාද වලින් දෝෂ සහිත UTF-8 ක්‍රියාත්මක කිරීම පසුගාමී අනුකූලතාව සඳහා පමණක් පවතී. ස්ථාවර අනුවාදයට නම ලබා දී ඇත utf8mb4.

සටහන: MySQL හි නවතම අනුවාදයන් යුනිකෝඩ් වර්ග කිරීමේ නීති යාවත්කාලීන කර ඇති utf8mb4_0900_ai_ci අතර යුනිකෝඩ් 9.0 මත පදනම් වූ සමාන නීති සඳහා නම් යටතේ ලබා ගත හැකිය _general . දැන් මෙය කියවන පුද්ගලයින් බොහෝ විට මෙම නව එකතුවෙන් එකක් _unicode හෝ භාවිතා කළ යුතුය_general . ඔබට ඒ වෙනුවට නව එකතුවක් භාවිතා කළ හැකි නම් පහත ලියා ඇති බොහෝ දේ වැඩි උනන්දුවක් නොදක්වයි.

ප්රධාන වෙනස්කම්

  • utf8mb4_unicode_ci විශ්වීය වර්ග කිරීම සහ සංසන්දනය සඳහා වන නිල යුනිකෝඩ් නීති මත පදනම් වන අතර එය පුළුල් පරාසයක භාෂා වලින් නිවැරදිව වර්ග කරයි.

  • utf8mb4_general_ciවේගය වැඩි දියුණු කිරීම සඳහා නිර්මාණය කර ඇති කෙටිමං බොහෝමයක් ගන්නා අතරම එය කළ හැකි මෙන්ම කළ හැකි සරල කළ වර්ග කිරීමේ නීති මාලාවකි. එය යුනිකෝඩ් රීති අනුගමනය නොකරන අතර විශේෂිත භාෂා හෝ අක්ෂර භාවිතා කරන විට වැනි සමහර අවස්ථාවන්හිදී අනවශ්‍ය ලෙස වර්ග කිරීම හෝ සංසන්දනය කිරීම සිදු වේ.

    නවීන සේවාදායකයන් මත, මෙම කාර්ය සාධනය වැඩි කිරීම නොසැලකිලිමත් වනු ඇත. එය නිර්මාණය කරන ලද්දේ වර්තමාන පරිගණකවල CPU ක්‍රියාකාරීත්වයේ ඉතා සුළු ප්‍රමාණයක් සේවාදායකයන්ට තිබූ කාලයක ය.

ප්රතිලාභ utf8mb4_unicode_ciවැඩිutf8mb4_general_ci

utf8mb4_unicode_ci, වර්ග කිරීම හා සංසන්දනය කිරීම සඳහා යුනිකෝඩ් නීති භාවිතා කරන, පුළුල් පරාසයක භාෂාවන්හි නිවැරදි වර්ග කිරීම සඳහා සහ පුළුල් පරාසයක විශේෂ අක්ෂර භාවිතා කිරීමේදී තරමක් සංකීර්ණ ඇල්ගොරිතමයක් භාවිතා කරයි. මෙම නීති භාෂා විශේෂිත සම්මුතීන් සැලකිල්ලට ගත යුතුය; සෑම කෙනෙකුම ඔවුන්ගේ චරිත අප 'අකාරාදී පිළිවෙල' ලෙස හඳුන්වන්නේ නැත.

ලතින් (එනම් "යුරෝපීය") භාෂා වලට අනුව, යුනිකෝඩ් වර්ග කිරීම සහ utf8mb4_general_ciMySQL හි සරල කළ වර්ග කිරීම අතර විශාල වෙනසක් නොමැත , නමුත් තවමත් වෙනස්කම් කිහිපයක් තිබේ:

  • උදාහරණ සඳහා, යුනිකෝඩ් එකතුව “ss” වැනි “ß” සහ “OE” වැනි “Œ” වැනි අක්ෂර සාමාන්‍යයෙන් භාවිතා කිරීමට අවශ්‍ය වන අතර utf8mb4_general_ciඒවා තනි අක්ෂර ලෙස වර්ග කරයි (අනුමාන වශයෙන් පිළිවෙලින් “s” සහ “e” වැනි) .

  • සමහර යුනිකෝඩ් අක්ෂර නොසලකා හැරිය හැකි ලෙස අර්ථ දක්වා ඇත, එයින් අදහස් කරන්නේ ඒවා වර්ග කිරීමේ අනුපිළිවෙලට ගණන් නොගත යුතු අතර සංසන්දනය ඒ වෙනුවට ඊළඟ අක්ෂරයට යා යුතුය. utf8mb4_unicode_ciමේවා නිසි ලෙස හසුරුවයි.

ආසියානු භාෂා හෝ විවිධ හෝඩිය සහිත භාෂා වැනි ලතින් නොවන භාෂාවල යුනිකෝඩ් වර්ග කිරීම සහ සරල කළ වර්ග කිරීම අතර තවත් බොහෝ වෙනස්කම් තිබිය හැකිය utf8mb4_general_ci. යෝග්‍යතාවය utf8mb4_general_ciභාවිතා කරන භාෂාව මත බෙහෙවින් රඳා පවතී. සමහර භාෂාවන් සඳහා එය ප්‍රමාණවත් නොවේ.

ඔබ භාවිතා කළ යුත්තේ කුමක්ද?

utf8mb4_general_ciCPU වේගය අඩු මට්ටමක පවතින බැවින් කාර්ය සාධන වෙනස වැදගත් වන තරමට අප තවදුරටත් භාවිතා කිරීමට කිසිදු හේතුවක් නැත. ඔබේ දත්ත සමුදාය මීට වඩා වෙනත් බාධක මගින් නිසැකවම සීමා වනු ඇත.

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

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

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

කොටස් වලින් අදහස් කරන්නේ කුමක්ද

පළමු වැන්න නම්, ciසඳහා නඩුව-අසංවේදී තෝරා බේරා ගැනීමේ සහ රකිති. මෙයින් අදහස් කරන්නේ එය පා data මය දත්ත සඳහා සුදුසු වන අතර නඩුව වැදගත් නොවන බවයි. csනඩුව වැදගත් වන පෙළ දත්ත සඳහා (සිද්ධි-සංවේදී) අනෙක් වර්ගවල එකතුවක් වන binඅතර, කේතන ක්‍රමයට ගැළපීමට අවශ්‍ය තැන, බිට් බිට්, ඇත්ත වශයෙන්ම කේතනය කරන ලද ද්විමය දත්ත සහිත ක්ෂේත්‍ර සඳහා සුදුසු වේ (නිදසුනක් ලෙස, ඇතුළුව) Base64). සිද්ධි සංවේදී වර්ග කිරීම සමහර අමුතු ප්‍රති results ල වලට තුඩු දෙන අතර සිද්ධි සංවේදී සංසන්දනය අනුපිටපත් අගයන් අකුරු නඩුවකින් පමණක් වෙනස් විය හැක, එබැවින් සිද්ධි සංවේදී සංයෝජන පෙළ දත්ත සඳහා අනුග්‍රහය නොලැබේ - නඩුව ඔබට වැදගත් නම්, නොසලකා හැරිය හැකි විරාම ලකුණු එසේ කිරීම බොහෝ විට වැදගත් වන අතර ද්විමය එකතුවක් වඩාත් යෝග්‍ය වේ.

ඊළඟට, unicodeහෝ generalනිශ්චිත වර්ග කිරීමේ හා සංසන්දනය කිරීමේ රීති වෙත යොමු වේ - විශේෂයෙන්, පෙළ සාමාන්‍යකරණය කරන හෝ සංසන්දනය කරන ආකාරය. Utf8mb4 අක්ෂර කේතනය සඳහා විවිධ නීති මාලාවක් ඇත, ඒවා දෙකක් unicodeසහ generalඑක් විශේෂිත එකකට වඩා හැකි සෑම භාෂාවකම හොඳින් වැඩ කිරීමට උත්සාහ කරයි. මෙම නීති මාලාවන් දෙක අතර ඇති වෙනස්කම් මෙම පිළිතුරේ මාතෘකාව වේ. unicodeයුනිකෝඩ් 4.0 වෙතින් නීති භාවිතා කරන බව සලකන්න . MySQL හි මෑත සංස්කරණ unicode_520යුනිකෝඩ් 5.2 හි නීති භාවිතා කරමින් රීසෙට් එකතු කරයි , සහ 0900("යුනිකෝඩ්_" කොටස අතහැර දමයි) යුනිකෝඩ් 9.0 හි නීති භාවිතා කරයි.

අවසාන වශයෙන්, utf8mb4ඇත්ත වශයෙන්ම අක්ෂර කේතනය අභ්‍යන්තරව භාවිතා වේ. මෙම පිළිතුරෙන් මම කතා කරන්නේ යුනිකෝඩ් පදනම් කරගත් කේතීකරණ ගැන පමණි.


220
ඔබ @KahWeeTeng යුතු නැහැ, මෙතෙක් භාවිතා utf8_general_ci: එය හුදෙක් වැඩ කරන්නේ නැහැ. එය වසර පනහකට පෙර සිට ASCII stooopeeedity හි නරක පැරණි දිනවලට තල්ලු කිරීමකි. යූසීඩී වෙතින් ෆෝල්ඩ්කේස් සිතියම නොමැතිව යුනිකෝඩ් කේස්-සංවේදී නොගැලපීම කළ නොහැක. උදාහරණයක් ලෙස, “Σίσυφος” හි විවිධ සිග්මා තුනක් ඇත; හෝ “TSCHüẞ” හි කුඩා අකුර “tschüβ” වන්නේ කෙසේද, නමුත් “tschüβ” හි ලොකු අකුර “TSCHÜSS” වේ. ඔබට නිවැරදි විය හැකිය, නැතහොත් ඔබට වේගවත් විය හැකිය. එබැවින් ඔබ භාවිතා කළ යුතුය utf8_unicode_ci, මන්ද ඔබ නිවැරදි බව ගැන තැකීමක් නොකරන්නේ නම්, එය අනන්තවත් වේගවත් කිරීම සුළුපටු ය.
tchrist

7
මෙය කියවීමෙන් පසු මම සොයාගත්තා utf8_unicode_ci සමානාත්මතා සංසන්දනය කිරීමේ අරමුණු සඳහා සමාන සංයුතියේ බර ඇති ඕනෑම අක්ෂර සමාන යැයි සලකනු ඇත. මෙය අවස්ථා වලදී "か" == "が"හෝ "ǽ" == "æ". මෙය වර්ග කිරීම අර්ථවත් නමුත් සමානතා හරහා තෝරාගැනීමේදී හෝ අද්විතීය දර්ශක සමඟ කටයුතු කිරීමේදී පුදුමයට කරුණක් විය හැකිය - bugs.mysql.com/bug.php?id=16526
Mat Schaffer

4
An ඩෑන්හෝර්වාට් ඔබ MySQL හි පැරණි, වඩා සීමිත යුනිකෝඩ් උප කාණ්ඩයට පමණක් සීමා වීමට ඇති එකම ප්‍රායෝගික හේතුව නම්, ඔබ සතුව MySQL හි පැරණි අනුවාදයක් තිබේ නම් එය වඩාත් සම්පූර්ණ utf8mb4 සඳහා සහය නොදක්වයි. 5.5.3 වයස අවුරුදු 5 ඉක්මවයි. මම Plesk වෙනස් MySQL කාලසටහන මත ධාවනය බව අගය කරනවා, නමුත් බොහෝ distros දැන් MySQL 5.5 සඳහා වන අතර Plesk 11.x කරන්නේ ඔබ එහි සංරචක යාවත්කාලීන ලබා දීමට නම් MySQL 5.5.
thomasrutter

24
නවතම, වඩා ප්‍රමිති-පැමිණිලි ප්‍රභේදය භාවිතා කිරීම නරක පුරුද්දක් බව මම එකඟ නොවෙමි, මේ වගේ දෙයක් ගැන මිනිසුන් නරක සංවර්ධකයින් ලෙස හැඳින්වීම ගිනි අවුලුවන බව මම සිතමි. මගේ පිළිතුර " MySQL හි නව සංස්කරණ වලදී utf8 වෙනුවට utf8mb4 භාවිතා කරන්න " යනුවෙන් සඳහන් කර ඇති බව ඔබට සටහන් කර ගැනීමට අවශ්‍ය විය හැකිය .
thomasrutter

26
නිවැරදි තේරීම ඩෑන්හෝර්වාට් utf8mb4ය . ඔබ සමඟ කළ යුත්තේ කුමක් ද යන්න දන්නා MySQL (සහ MariaDB) පමණක් UTF8 හි 3-බයිට් ප්‍රභේදයක් තුළ ය. සෙසු ලෝකය UTF8 භාවිතා කරයි, එය අක්ෂරයකට බයිට් 4 ක් දක්වා අඩංගු විය හැකිය . MySQL devs ඔවුන්ගේ හෝම්බ rew කේතීකරණය වැරදි ලෙස නම් කර ඇති අතර පසුගාමී අනුකූලතාව බිඳ නොදැමීම සඳහා ඔවුන්ට දැන් සැබෑ UTF8 ලෙස හැඳින්විය යුතුය. utf8utf8utf8mb4
ස්ටිජන් ඩි විට්

165

භාවිතා කිරීම utf8_general_ciසහ කාර්ය සාධනය අතර ඇති වෙනස කුමක්දැයි දැන ගැනීමට මට අවශ්‍ය විය utf8_unicode_ci, නමුත් අන්තර්ජාලයේ ලැයිස්තුගත කර ඇති කිසිදු මිණුම් සලකුණු මට හමු නොවීය, එබැවින් මා විසින්ම මිණුම් සලකුණු නිර්මාණය කිරීමට තීරණය කළෙමි.

පේළි 500,000 ක් සහිත ඉතා සරල වගුවක් මම නිර්මාණය කළෙමි:

CREATE TABLE test(
  ID INT(11) DEFAULT NULL,
  Description VARCHAR(20) DEFAULT NULL
)
ENGINE = INNODB
CHARACTER SET utf8
COLLATE utf8_general_ci;

මෙම ගබඩා කළ ක්‍රියා පටිපාටිය ක්‍රියාත්මක කිරීමෙන් මම එය අහඹු දත්ත වලින් පුරවා ගත්තෙමි:

CREATE PROCEDURE randomizer()
BEGIN
  DECLARE i INT DEFAULT 0;
  DECLARE random CHAR(20) ;
  theloop: loop
    SET random = CONV(FLOOR(RAND() * 99999999999999), 20, 36);
    INSERT INTO test VALUES (i+1, random);
    SET i=i+1;
    IF i = 500000 THEN
      LEAVE theloop;
    END IF;
  END LOOP theloop;
END

සරල SELECT, SELECTසමඟ LIKEසහ වර්ග කිරීම ( SELECTසමඟ ORDER BY) මිණුම් සලකුණු කිරීම සඳහා මම පහත ගබඩා කළ ක්‍රියා පටිපාටි නිර්මාණය කළෙමි :

CREATE PROCEDURE benchmark_simple_select()
BEGIN
  DECLARE i INT DEFAULT 0;
  theloop: loop
    SELECT *
    FROM test
    WHERE Description = 'test' COLLATE utf8_general_ci;
    SET i = i + 1;
    IF i = 30 THEN
      LEAVE theloop;
    END IF;
  END LOOP theloop;
END;

CREATE PROCEDURE benchmark_select_like()
BEGIN
  DECLARE i INT DEFAULT 0;
  theloop: loop
    SELECT *
    FROM test
    WHERE Description LIKE '%test' COLLATE utf8_general_ci;
    SET i = i + 1;
    IF i = 30 THEN
      LEAVE theloop;
    END IF;
  END LOOP theloop;
END;

CREATE PROCEDURE benchmark_order_by()
BEGIN
  DECLARE i INT DEFAULT 0;
  theloop: loop
    SELECT *
    FROM test
    WHERE ID > FLOOR(1 + RAND() * (400000 - 1))
    ORDER BY Description COLLATE utf8_general_ci LIMIT 1000;
    SET i = i + 1;
    IF i = 10 THEN
      LEAVE theloop;
    END IF;
  END LOOP theloop;
END;

ඉහත ගබඩා ක්රමවේදයන් utf8_general_ciසංචයන අගයක් භාවිතා, නමුත් මම යන දෙකම භාවිතා කරන පරීක්ෂණ තුළ ඇත්ත ඇත utf8_general_ciහා utf8_unicode_ci.

මම එක් එක් එකතුව සඳහා 5 වතාවක් (5 වතාවක් utf8_general_ciසහ 5 වතාවක් utf8_unicode_ci) අමතා සාමාන්‍ය අගයන් ගණනය කළෙමි .

මගේ ප්‍රති results ල:

benchmark_simple_select()

  • සමග utf8_general_ci: 9,957 ms
  • සමග utf8_unicode_ci: 10,271 ms

මෙම මිණුම් ලකුණෙහි භාවිතය 3.2% utf8_unicode_ciට වඩා මන්දගාමී වේ utf8_general_ci.

benchmark_select_like()

  • සමග utf8_general_ci: 11,441 ms
  • සමග utf8_unicode_ci: 12,811 ms

මෙම මිණුම් ලකුණෙහි භාවිතය 12% utf8_unicode_ciට වඩා මන්දගාමී වේ utf8_general_ci.

benchmark_order_by()

  • සමග utf8_general_ci: 11,944 ms
  • සමග utf8_unicode_ci: 12,887 ms

මෙම මිණුම් ලකුණෙහි භාවිතය 7.9% utf8_unicode_ciට වඩා මන්දගාමී වේ utf8_general_ci.


16
හොඳ මිණුම් ලකුණක්, බෙදාගැනීම ගැන ස්තූතියි. මට සංවේදීව සමාන සංඛ්‍යා (වින්ඩෝස් හි MySQL v5.6.12) ලැබේ: 10%, 4%, 8%. මම එකඟ වෙමි: කාර්ය සාධනය ඉහළ නැංවීම utf8_general_ciභාවිතා කිරීම වටී.
RandomSeed

10
1) නමුත් මෙම මිණුම් ලකුණ අර්ථ දැක්වීම අනුව සංයෝජන දෙක සඳහා සමාන ප්‍රති results ල ලබා දිය යුතු නොවේද? මම අදහස් කළේ CONV(FLOOR(RAND() * 99999999999999), 20, 36)උත්පාදනය කරන්නේ ASCII පමණක් වන අතර, යුනිකෝඩ් අක්ෂර සැකසීමේ ඇල්ගොරිතම මඟින් සැකසිය යුතු නොවේ. 2) Description = 'test' COLLATE ...සහ Description LIKE 'test%' COLLATE ...ධාවන වේලාවේදී තනි නූලක් ("පරීක්ෂණය") පමණක් සකසන්න, එසේ නොවේ ද? 3) තාත්වික යෙදුම්වල, ඇණවුම් කිරීමේදී භාවිතා කරන තීරු බොහෝ විට සුචිගත කර ඇති අතර සැබෑ ASCII නොවන පෙළ සමඟ විවිධ සංයෝජනයන්හි සුචිගත කිරීමේ වේගය වෙනස් විය හැකිය.
හැලිල් Özgür

2
@ හැලිලෙස්ගර් - ඔබේ අදහස අර්ධ වශයෙන් වැරදිය. මම (එය general_ci නිවැරදිව හැසිරවීම ඇත) පිටත ASCII වීමට codepoint වටිනාකම ගැන නොවේ, නමුත් "සමගින් ලෙස ලියා umlauts ප්රතිකාර වැනි විශේෂිත ලක්ෂණ, මේ ගැන කුහකකමකින් EA UTE" හෝ සමහර එවන් සූක්ෂ්ම.
ටොමාස් ගන්ඩෝර්

38

මෙම ලිපිය එය ඉතා සියුම් ලෙස විස්තර කරයි.

කෙටියෙන් කිවහොත්: utf8_unicode_ci යුනිකෝඩ් ප්‍රමිතිවල අර්ථ දක්වා ඇති පරිදි යුනිකෝඩ් එකතුව ඇල්ගොරිතම භාවිතා කරන අතර utf8_general_ci යනු වඩාත් සරල වර්ග කිරීමේ අනුපිළිවෙලක් වන අතර එමඟින් “අඩු නිරවද්‍ය” වර්ග කිරීමේ ප්‍රති .ල ලැබේ.


1
ස්තූතියි. ඒක තමයි මගේ හැඟීම. මම කාර්ය සාධනය
ඉහළට ගන්නම්

7
ඔබ නිවැරදි බව ගැන තැකීමක් නොකරන්නේ නම්, ඕනෑම ඇල්ගොරිතමයක් අනන්තවත් වේගවත් කිරීම සුළුපටු ය. භාවිතා utf8_unicode_ciකර අනෙකා නොපවතින ලෙස මවාපානවා.
tchrist

1
ක්‍රිස්තුස් නමුත් ඔබ නිවැරදි බව සහ වේගය අතර යම් සමබරතාවයක් ගැන සැලකිලිමත් වන්නේ නම්, ඔබ utf8_general_ciවෙනුවෙන් විය හැකිය
ෂෙල්වාකු

chtchrist කිසි විටෙකත් ක්‍රීඩා ක්‍රමලේඛකයෙකු නොවන්න;)
Stijn de Witt

1
assonassar - MySQL 8.0 කියා සිටින්නේ සියලුම සංයෝගවල ක්‍රියාකාරිත්වය සැලකිය යුතු ලෙස වැඩි දියුණු කර ඇති බවයි.
රික් ජේම්ස්

9

MySQL අත්පොත, යුනිකෝඩ් අක්ෂර කට්ටල කොටස බලන්න:

ඕනෑම යුනිකෝඩ් අක්ෂර කට්ටලයක් සඳහා, _ජෙනරල්_සි එකතුව භාවිතා කරමින් සිදුකරන මෙහෙයුම් _ යුනිකෝඩ්_සි එකතුවට වඩා වේගවත් වේ. උදාහරණයක් ලෙස, utf8_general_ci එකතුව සඳහා සංසන්දනයන් utf8_unicode_ci සඳහා සැසඳීම් වලට වඩා වේගවත් නමුත් තරමක් අඩු නිවැරදි ය. මෙයට හේතුව utf8_unicode_ci පුළුල් කිරීම වැනි සිතියම්කරණයට සහාය වීමයි; එනම්, එක් අක්ෂරයක් අනෙක් අක්ෂරවල සංයෝජනයන්ට සමාන වන විට. උදාහරණයක් ලෙස, ජර්මානු සහ වෙනත් භාෂාවලින් “ß” “ss” ට සමාන වේ. utf8_unicode_ci ද හැකිලීම් සහ නොසලකා හරින අක්ෂර සඳහා සහය දක්වයි. utf8_general_ci යනු පුළුල් කිරීම්, හැකිලීම් හෝ නොසලකා හරින අක්ෂර සඳහා සහාය නොදක්වන උරුම එකතුවකි. එය කළ හැක්කේ අක්ෂර අතර සැසඳීම් එකක් පමණි.

සාරාංශගත කිරීම සඳහා, utf_general_ci utf_unicode_ci ට වඩා කුඩා හා අඩු නිවැරදි (සම්මතයට අනුව) සැසඳීම් මාලාවක් භාවිතා කරයි, එය සමස්ත ප්‍රමිතිය ක්‍රියාත්මක කළ යුතුය . ගණනය කිරීම අඩු බැවින් general_ci කට්ටලය වේගවත් වේ.


18
“තරමක් අඩු නිවැරදි” වැනි දෙයක් නොමැත. නිවැරදිභාවය යනු බූලියන් ලක්ෂණයකි; එය උපාධි වෙනස් කිරීම් පිළිගන්නේ නැත. යන්තම් භාවිතා utf8_unicode_ciවන සපිරි බිඳ අනුවාදය නොපවතියි හා බොරුවට.
tchrist

2
Collation_connection සැකසුම ගැනීමට මට 5.6.15 ක් ලබා ගැනීමේ ගැටළු ඇති අතර, ඔබ එය 'SET NAMES utf8mb4 COLLATE utf8mb4_unicode_ci' වැනි SET රේඛාවෙන් සමත් විය යුතු බව පෙනේ. ණය මුදල විසඳුම සඳහා මතියස් බයිනස් වෙත ය, මෙන්න ඔහුගේ ඉතා ප්‍රයෝජනවත් මාර්ගෝපදේශය: mathiasbynens.be/notes/mysql-utf8mb4
ස්ටීව් හිබර්ට්

4
ristchrist නිවැරදි බව පැවසීමේ ගැටළුව බූලියන් වන අතර එය නිරපේක්ෂ නිරවද්‍යතාව මත රඳා නොපවතින තත්වයන් සැලකිල්ලට නොගනී. ඔබේ මූලික කරුණ අවලංගු නොවේ. මම සාමාන්‍ය_සී හි ප්‍රතිලාභ ගැන කතා කිරීමට උත්සාහ නොකරමි, නමුත් නිවැරදිභාවය පිළිබඳ ඔබේ සාමාන්‍ය ප්‍රකාශය පහසුවෙන් ප්‍රතික්ෂේප කළ හැකිය. මම එය මගේ වෘත්තියේ දිනපතාම කරමි. හාස්‍යය පසෙකට දැමුවහොත්, ස්ටුවර්ට්ට මෙහි හොඳ කරුණක් තිබේ .
ඇන්තනි

5
භූ ස්ථානගත කිරීම හෝ ක්‍රීඩා සංවර්ධනය සමඟ අපි නිරතුරුවම කාර්ය සාධනය සමඟ වෙළඳාම් කරන්නෙමු. හා පාඨමාලා නිවැරදි භාවය අතර ඇත්ත සංඛ්යාව 0සහ 1ඉතා bool, නැත. :) EG මායිම් පෙට්ටියක භූ ලක්ෂ්‍ය තෝරා ගැනීම යනු 'අසල ඇති ලක්ෂ්‍යයන්' ආසන්න වශයෙන් දැක්වීමකි, එය ලක්ෂ්‍යය සහ යොමු ලක්ෂ්‍යය අතර දුර ගණනය කිරීම හා ඒ මත පෙරීම තරම් හොඳ නොවේ. නමුත් දෙකම දළ වශයෙන් වන අතර ඇත්ත වශයෙන්ම සම්පූර්ණ නිරවද්‍යතාවය බොහෝ දුරට අත් කරගත නොහැකිය. බලන්න වෙරළ තීරය විරුද්ධාභාෂය හා IEEE 754
Stijn ද Witt

4
TL; DR : කරුණාකර නිවැරදි1/3
ප්‍රති

7

කෙටි වචන වලින්:

ඔබට වඩා හොඳ වර්ග කිරීමේ අනුපිළිවෙලක් අවශ්‍ය නම් - භාවිතා කරන්න utf8_unicode_ci(මෙය වඩාත් කැමති ක්‍රමයයි),

නමුත් ඔබ කාර්ය සාධනය ගැන මුළුමනින්ම උනන්දු වන්නේ නම් - භාවිතා කරන්න utf8_general_ci, නමුත් එය ටිකක් යල් පැන ගිය එකක් බව දැන ගන්න.

කාර්ය සාධනය අනුව වෙනස්කම් ඉතා සුළු ය.


1
දෙකම දැන් යල් පැන ඇත - වැඩි විස්තර සඳහා පිළිගත් පිළිතුර බලන්න
තෝමස්රටර්

6

සමහර විස්තර (පීඑල්)

අපට මෙහි කියවිය හැකි පරිදි ( පීටර් ගුලුට්සාන් ) ඔප දැමීමේ අකුරු "-" වර්ග කිරීම / සංසන්දනය කිරීමෙහි වෙනසක් ඇත (L සමඟ ආ Łroke ාතය - html esc :) (කුඩා අවස්ථාව: "ł" - html esc :) ł- අපට පහත උපකල්පනයක් ඇත:

utf8_polish_ci      Ł greater than L and less than M
utf8_unicode_ci     Ł greater than L and less than M
utf8_unicode_520_ci Ł equal to L
utf8_general_ci     Ł greater than Z

පොලිෂ් භාෂාවෙන් අකුරට Łපසුව Lසහ ඊට පෙර M. මෙම කේතීකරණ කිසිවක් වඩා හොඳ හෝ නරක නැත - එය ඔබගේ අවශ්‍යතා මත රඳා පවතී.


1

වර්ග කිරීම සහ චරිත ගැලපීම අතර විශාල වෙනසක් තිබේ:

වර්ග කිරීම :

  • utf8mb4_general_ci වැරදි උච්චාරණ ප්‍රති .ල ඇති කළ හැකි සියලුම උච්චාරණ සහ වර්ග එකින් එක ඉවත් කරයි.
  • utf8mb4_unicode_ci වර්ග නිවැරදි.

චරිත ගැලපීම

ඔවුන් චරිත එකිනෙකට වෙනස් ලෙස ගැලපේ.

නිදසුනක් වශයෙන්, utf8mb4_unicode_ciඔබ තුළ ඇත i != ı, නමුත් utf8mb4_general_ciඑය රඳවා තබා ගනී ı=i.

උදාහරණයක් ලෙස, ඔබට පේළියක් ඇතැයි සිතන්න name="Yılmaz". ඉන්පසු

select id from users where name='Yilmaz';

collocation නම් පේළිය බවත් නැවත utf8mb4_general_ci, නමුත් එය සමඟ collocated නම් utf8mb4_unicode_ciඑය වනු ඇත නොවන පේළිය නැවත!

අනෙක් අතට අපි ඇති a=ªහා ß=ssතුළ utf8mb4_unicode_ciදී නඩුව නොවන utf8mb4_general_ci. ඒ නිසා ඔබ සමඟ පේළියේ ඇති හිතාගන්න name="ªßi"පසුව,

select id from users where name='assi';

oc ට්ටනය නම් පේළිය නැවත ලබා දෙනු ඇත utf8mb4_unicode_ci, නමුත් ගැටීම සකසා ඇත්නම් පේළියක් ආපසු නොදෙනු ඇත utf8mb4_general_ci.

එක් එක් oc ට්ටනය සඳහා තරඟවල සම්පූර්ණ ලැයිස්තුවක් මෙහි සොයාගත හැකිය .


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.