ecshop でスケジュールされたタスクを実装するために、最初に私の考えを話しますので、皆さんのアイデアを教えてください。

要件の説明:

ユーザー テーブルには約 100 万件のユーザー レコードがあります。ここで、登録時刻 (create_time) フィールド (user_type new new user old old user) に基づいて、ユーザーが古いユーザーであるか新しいユーザーであるかを判断します。新規ユーザー: 2 週間以内、14 日以内 (両端を含む) に登録してください。
2. 古いユーザー: 2 週間以上、14 日以上 (例外) 登録しています。
私の考えは次のとおりです:

ECShop は純粋な OOP フレームワークではないため、ルート ディレクトリに crontab ディレクトリを作成する予定です

その中に新しい user.php を作成します

User.php はまずテーブル全体のレコードの総数をカウントします
次に 100 を取得しますページングでのレコードとループ更新 テーブル全体のデータ
クエリを実行するとき、where 条件フィルターはすでに古いユーザーのデータです
つまり、where は常に user_type='new' であり、テーブル全体のデフォルトは全く新しい

ここで問題が発生します。PHP スクリプトを実行すると、データベース MySQL がダウンしてしまうのではないかと心配です。どうすればよいですか?

1 ページあたり 100 のエントリを持つ 100 万のデータ、つまり 10,000 ページに対処する方法

この for ループの考え方は信頼できますか?

返信内容:

要件の説明:

ユーザー テーブルには約 100 万件のユーザー レコードがあります。ここで、登録時刻 (create_time) フィールド (user_type new new user old old user) に基づいて、ユーザーが古いユーザーであるか新しいユーザーであるかを判断します。新規ユーザー: 2 週間以内、14 日以内 (両端を含む) に登録してください。

2. 古いユーザー: 2 週間以上、14 日以上（除外）登録されています。

私の考えは次のとおりです:

ECShop は純粋な OOP フレームワークではないため、ルート ディレクトリに crontab ディレクトリを作成する予定です
その中に新しい user.php を作成します
User.php はまずテーブル全体のレコードの総数をカウントします
次に 100 を取得しますページングでのレコードとループ更新 テーブル全体のデータ
クエリを実行するとき、where 条件フィルターはすでに古いユーザーのデータです

つまり、where は常に user_type='new' であり、テーブル全体のデフォルトは新しい

ここで問題が発生します。PHP スクリプトを実行すると、データベース MySQL がダウンしてしまうのではないかと心配です。

1 ページあたり 100 のエントリを持つ 100 万のデータ、つまり 10,000 ページに対処する方法
この for ループの考え方は信頼できますか?

この問題について急いで取り組むべきではないと思います。最初に需要を分析するのが良いでしょう。重要なのは、古いユーザーと新しいユーザーの違いは何かということです。同時に、バッチ操作が含まれるかどうか (たとえば、グループ内の古いユーザーに Web サイト メッセージを送信するのはバッチ操作ですが、現在のユーザーが古いユーザーでない限り、特定のオファーは使用できません。これはバッチ操作ではありません)。 。

多くの場合、古いユーザーと新しいユーザーの区別は、本質的な変更を加えずに表示されるだけであるか、常に現在のログイン ユーザーに適用されます。現時点では、user_type フィールドを追加して現在のユーザーを直接決定する必要はありません。 create_time - time( ) が 14

24

60*60 より大きい場合は十分です。

この機能が本当に必要な場合は、あまり心配しないで、詳細に注意してください:

1- 最初の更新は 1 つの更新ステートメントで行うことができます。データベース上で直接実行します (ステートメントが正しいことを何度も確認してください))、思っているよりもはるかに高速です。

2- スケジュールされた更新: 毎回チェックを実行する必要があるのは、user_type = new および create_time < のユーザーだけであり、全員ではないため、パフォーマンスの問題はありません。この14日間で10万人登録できるでしょうか？ user_type フィールドと create_time フィールドにはインデックスを付ける必要があります。これは効率を向上させるためにも必要です。

1 つのステートメントが実行された後、バッチで直接更新されます。 現在の時間 - (作成時間 + 86400*14) UPDATE ユーザー SET user_type = 'old' WHERE (unix_timestamp(now()) - (create_time+86400*14))

データベースの増加を評価できます。実際、今日を変更して毎日古いユーザーになることができるため、フィルタリングされるデータの量が大幅に削減されます

ユーザーテーブルのcreate_timeにインデックスを追加し（インデックスフィールドはwhereの左側に配置する必要があります）、次のSQLを実行します。
リーリー

毎日午前3時に実行するだけ（切り捨て）、100万個のデータはそれほど多くありません