84669 人が学習中
152542 人が学習中
20005 人が学習中
5487 人が学習中
7821 人が学習中
359900 人が学習中
3350 人が学習中
180660 人が学習中
48569 人が学習中
18603 人が学習中
40936 人が学習中
1549 人が学習中
1183 人が学習中
32909 人が学習中
光阴似箭催人老,日月如移越少年。
テーブル名が user であると仮定します:
select * from user group by (...) having count(*) > 1 で十分なので、使用する必要はありません。 実際のところ、これは設計上のミスであり、一度修正してから、このような問題が再発しないようにテーブル構造を変更することが根本的な原因です。
select * from user group by (...) having count(*) > 1
また、このテーブルはIDを持たないため、条件を書き込めず重複したデータを自動的に削除することができず、削除するには中間テーブルを使用するしかありません。
要約すると、効率を考慮せず、手動で修正するだけです。
リーリー
テーブル GROUP BY 全体が関係するため、パフォーマンスは比較的低くなります。 テーブル構造を変更できる場合は、データの書き込み時にユーザー名が同じかどうかを判断して維持できるフィールドを追加することをお勧めします。
GROUP BY
データベースの世界には魔法はありません。インデックスによって検索が高速化されるのは、毎回データの挿入と更新にかかる時間が延長されるため、検索の高速化にはコストがかかります。
この質問に戻りますが、名前にインデックスを追加すると、グループ化がより効率的になりますが、ニーズに応じてサブクエリが必要になります。
しかし、名前にインデックスを追加するのは健全なアプローチだとは思いません。私だったら、この問題を解決するためにスケジュールされたタスクを実行します。同じ名前のユーザーをスキャンし、その ID を特定のテーブル A に記録します。その後、ページに表示されたら、テーブル A を取り出してユーザー テーブルに関連付けます。もう一つの理由は、この作品はそれほど厳密である必要はなく、現実と多少の乖離があっても構わないということです。
テーブル名が user であると仮定します:
リーリーselect * from user group by (...) having count(*) > 1
で十分なので、使用する必要はありません。実際のところ、これは設計上のミスであり、一度修正してから、このような問題が再発しないようにテーブル構造を変更することが根本的な原因です。
また、このテーブルはIDを持たないため、条件を書き込めず重複したデータを自動的に削除することができず、削除するには中間テーブルを使用するしかありません。
要約すると、効率を考慮せず、手動で修正するだけです。
リーリー
テーブル
GROUP BY
全体が関係するため、パフォーマンスは比較的低くなります。テーブル構造を変更できる場合は、データの書き込み時にユーザー名が同じかどうかを判断して維持できるフィールドを追加することをお勧めします。
データベースの世界には魔法はありません。インデックスによって検索が高速化されるのは、毎回データの挿入と更新にかかる時間が延長されるため、検索の高速化にはコストがかかります。
この質問に戻りますが、名前にインデックスを追加すると、グループ化がより効率的になりますが、ニーズに応じてサブクエリが必要になります。
しかし、名前にインデックスを追加するのは健全なアプローチだとは思いません。私だったら、この問題を解決するためにスケジュールされたタスクを実行します。同じ名前のユーザーをスキャンし、その ID を特定のテーブル A に記録します。その後、ページに表示されたら、テーブル A を取り出してユーザー テーブルに関連付けます。もう一つの理由は、この作品はそれほど厳密である必要はなく、現実と多少の乖離があっても構わないということです。