このクエリをより高速に実行するにはどうすればよいですか？

インデックス

必要です-少なくとも -JOINで使用されるすべてのフィールドのインデックス状態。
WHEREに表示されるフィールドのインデックスまたはGROUP BY またはORDER BY ほとんどの場合、句も役立ちます。
テーブル内で2つ以上のフィールドがJOIn（またはWHEREまたはGROUPBYまたはORDERBY）で使用されている場合、これらの（2つ以上の）フィールドの複合（結合）インデックスは、個別のインデックスよりも優れている場合があります。たとえば、SiteNumbers テーブルでは、可能なインデックスは複合(number_accountid, number_active)です。または(number_active, number_accountid) 。
ブール値（ON / OFF、アクティブ/非アクティブ）のフィールドの条件は、クエリの速度を低下させることがあります（インデックスは選択的ではないため、あまり役に立ちません）。その場合、テーブルの再構築（父による正規化）はオプションですが、おそらく複雑さの増大を回避できます。

通常のアドバイスに加えて（EXPLAINプランを調べ、必要に応じてインデックスを追加し、クエリのバリエーションをテストします）、

クエリに部分的なデカルト積があることに気付きました。テーブルAccounts 3つのテーブルに対して1対多の関係がありますFTPDetails 、SiteNumbers およびPPC 。これには、たとえば1000個のアカウントがあり、すべてのアカウントがたとえば10個のFTPDetails、20個のSiteNumber、および3個のPPCに関連している場合、クエリはすべてのアカウントに対して600行（10x20x3の積）を返すという効果があります。多くのデータが複製される合計60万行。

代わりに、クエリをベースデータ（アカウントと残りのテーブル）用に3つと1つに分割することができます。そうすれば、34K行のデータ（長さが短い）のみが転送されます：

Accounts JOIN Clients JOIN Users 
  (with all fields needed from these tables)
  1K rows

Accounts JOIN FTPDetails
  (with Accounts.account_id and all fields from FTPDetails)
  10K rows

Accounts JOIN SiteNumbers
  (with Accounts.account_id and all fields from SiteNumbers)
  20K rows

Accounts JOIN PPC
  (with Accounts.account_id and all fields from PPC)
  3K rows

次に、クライアント側の4つのクエリのデータを使用して、結合された情報を表示します。

次のインデックスを追加します：

Table Accounts
  index on (account_designer)
  index on (account_client)
  index on (account_active, account_id)
  index on (account_update)

Table FTPDetails
  index on (ftp_active, ftp_accountid)

Table SiteNumbers
  index on (number_active, number_accountid)

Table PPC
  index on (ppc_active, ppc_accountid)