Účinky aktualizace tabulky s řádky z utf8_turkish_ci na utf8_general_ci?

Data vašich sloupců jsou uložena pomocí znakové sady. V tomto případě se zdá, že je to utf8.

Když pracujete s těmito sloupci (provádíte například porovnávání rovnosti nebo řazení), MySQL používá porovnávání. Každý sloupec má výchozí řazení, které zdědí z výchozího řazení tabulky.

Indexy mají v sobě uloženo výchozí řazení sloupce, takže mohou efektivně fungovat.

Můžete provést srovnání rovnosti, které je kvalifikováno porovnáváním. Například v JOIN můžete specifikovat

ON (turkish.village_name COLLATE utf8_general_ci) = euro.village_name

nebo možná

ON turkish.village_name = (euro.village_name COLLATE utf8_turkish_ci)

To by mělo eliminovat váš nelegální mix porovnávání, aniž byste museli měnit svůj stůl. To vám může pomoci vyhnout se změně databáze, na kterou se ptáte. Ale pozor, pomocí COLLATE kvalifikátor může zabránit použití indexu. Pokud máte velkou tabulku a spoléháte se na výkon indexů, nemusí to být užitečné.

Co se tedy stane, když změníte své tabulky, abyste změnili výchozí řazení?

1. Vaše data se nezmění (pokud nezměníte také znakovou sadu). To je dobře.
2. Všechny indexy obsahující sloupce s kolacemi budou znovu vygenerovány.
3. Vaše srovnání a objednávky se mohou změnit. Neumím turecky, takže vám nemůžu říct, co by se mohlo zlomit. Ale například ve španělštině písmena N a Ñ nejsou stejné. N přichází před Ñ ve španělském řazení, ale v obecném řazení se s nimi zachází jako se stejným. Některé aspekty turecké abecedy mohou fungovat stejně, takže ORDER BY výsledky budou nesprávné.

Můžete to však opravit zadáním COLLATE modifikátor ve vašem ORDER BY klauzule.

ORDER BY (euro.village_name COLLATE utf8_turkish_ci)