受け入れられた答えが照合ではなくエンコードについて語っているので、（2015-04-20、「どの照合[...]」に）記載されているような質問は意味がありません。興味深いと思うからといって、意図した質問ではなく、述べられている質問に答えさせてください:-)
ウィキペディアによると、「照合とは、書かれた情報を標準的な順序にまとめることです」。コンピューティングでは、照合は「そのような順序の仕様」の意味を引き継ぎました。言い換えると、照合とは、3者間比較関数の定義（または暗示）です。
短い答えは「間違いなく多分」だと思います。少なくとも、私は次のシェナンガンを知っています。
#!/usr/bin/python
name = u"Jonas K\xf6lker" # \xf6 is o-umlaut
enc = name.encode('utf-8')
assert len(name) == 12 # \xf6 is one character
assert len(enc) == 13 # but two bytes in utf-8
import locale
locale.setlocale(locale.LC_COLLATE, "da_DK.utf8") # works on my machine
long_form = locale.strxfrm(enc)
assert len(long_form) == 38
locale.strxfrmは、Returns a string that behaves for cmp locale-aware文字列をエンコードする関数です。つまり、同様にエンコードされた別の文字列とのバイト単位の標準辞書式比較により、ロケールで指定された照合関数に従って文字列を比較するのと同じ結果が生成されます。
いくつかの観察：in da_DK.utf8では、文字列ouüöがソートされます。ではde_DE.utf8、文字列oöuüがソートされます。len(long_form) == 3838と13に注意してください（長さも38インチde_DE.utf8です）。
データベースがに基づいて照合された文字列フィールドにインデックスを持っている場合、単純な比較を行うために内部的に次のようなことをしてda_DK.utf8いる可能性がありstrxfrmます。（一方、ディスクは低速です。文字ごとの比較コストが高いほど、より少ない文字を比較することでオフセットを超える場合、よりコンパクトな表現に基づいてインデックスを作成する方が高速になる場合があります。）
「照合はクエリの速度に影響しますか？」da_DK.utf8）およびドイツ語（de_DE.utf8）ロケールは、さらに注意が必要です。これはクエリの速度にある程度の影響がありますが、心配する価値はないと思います。
「照合順序によってテーブルのサイズは変わりますか？」—ある照合に応じたインデックスと、別の照合に応じた異なるインデックス、またはそのような2つのインデックスのうちの1つに、何らかのstrxfrm変換を適用したものを想像できます。この仮想シナリオでは、サイズの特性が異なる2つの照合がある場合、答えは「はい」です。
「推奨される照合はどれですか？」—それは、文字列をソートする必要がある理由に依存します。文字列を順序付ける標準的な方法があるだけの場合は、おそらく「C」を使用します。データを人間の期待に従ってソートされた順序でユーザーに提示し、それらの期待が彼らの文化によって形作られており、データベース（他のレイヤーではなく）がソートを実行したい場合、おそらく照合ごとに1つのインデックスを構築する必要があります、すなわち、少なくとも1つda_DK.utf8はデンマーク人向け、もう1つde_DE.utf8はドイツ人向け。ただし、これはかなり急速に大きくなると思います。
これらはすべて、データベースの内部動作に大きく依存しています。「標準化された」SQLをはるかに超えると思います（笑！）。いつものように、特定のデータベースシステムのドキュメントを参照してください。