1

私は私を悩ませている問題を抱えています！

数千人のユーザーがいるデータベースがあります。データは元々、データを信頼できないデータベースからのものだったので、別の「クリーンアップ」データベースにインポートして、重複したエントリを削除しました。

私はクエリを実行しました：

SELECT uid, username 
FROM users
GROUP BY username 
HAVING COUNT(username)>1

これは、現在の状態のテーブルのサンプルです。

uid     forename     surname     username
1       Jo           Bloggs      jobloggs
2       Jo           Bloggs      jobloggs
3       Jane         Doe         janedoe
4       Jane         Doe         janedoe

上記のクエリを実行すると、次のサンプル結果が得られます。

uid     forename     surname     username
2       Jo           Bloggs      jobloggs

ご覧のとおり、重複するユーザーが 2 人いますが、クエリにはそのうちの 1 つしか表示されていません。

クエリを実行すると、300 ~ の結果が得られます。明らかに、クエリがすべての重複をプルしていない場合、この結果セットが正確であるとは信じられず、クリーンアップを続行できません。

私が何を試すことができるかについて何か考えはありますか？

ありがとう

フィル

4

1 に答える 1

0

返される結果セットについての適切な説明はありません。

サンプル データとクエリによると、2 行目を取得する必要があります。

3   janedoe

(実際には、返される uid 値が 3 か 4 かは任意です。)

また、クライアントが行のサブセットのみを返していることを確認してください。たとえば、SQLyog には、返される行数を制限する「行の制限」機能があります。

それが問題でない場合、最も可能性の高い説明は、「janedoe」の 1 つに印刷できない文字が含まれているか、2 つの異なるエンコーディングが同じ値を表示している場所で、いくつかの邪悪な文字セット変換が行われていることです。

最初の簡単なステップとして、これらの「janedoe」値のそれぞれの文字数を確認することをお勧めします。

SELECT username, LENGTH(username) FROM mytable WHERE uid IN (3,4) ORDER BY uid

また、HEX() 関数を使用して実際のエンコーディングを表示して、違いがあるかどうかを確認することもできます。(注: 文字セットの変換が HEX の前または後に発生するかどうかは明確ではありません。ここで求めているのは、Oracle DUMP() 関数に相当する MySQL であり、実際の値のバイト単位の表現を表示します。 )

Latin1 エンコーディングを UTF-8 に変更したり、その逆にしたり、その他の文字セットの異常が発生している可能性があります。これはあなたにいくつかのアイデアを与えるかもしれません...

SELECT username
     , HEX(username)
     , HEX(BINARY username)
     , CONVERT(BINARY username USING latin1) 
     , CONVERT(BINARY username USING utf8)
  FROM mytable 
 WHERE uid IN (3,4)
 ORDER BY uid
于 2012-12-20T23:14:04.233 に答える