1

前に尋ねた質問/問題に行き詰まりました – AVG クエリ用にテーブルを最適化する方法は? @MichaelT が 1 つの点で正しかったことが判明しました。AVG の計算は、MySQL よりも PHP を使用した方が高速です (5m レコードと 24 GB RAM マシンで 80% 高速など)。

それは常にオプションでさえありません。ただし、このコード例 (データセット サイズ 5m レコード) を検討してください。

MySQL のやり方。

1) 集計データ（一時データ作成）（500ms）

CREATE TEMPORARY TABLE `temporary_grouped_data` AS
(
    SELECT
        `r1`.`id`,
        `c1`.`wt`,
        `c1`.`cpu`,
        `c1`.`mu`,
        `c1`.`pmu`
    FROM
        `requests` `r1`
    INNER JOIN
        `request_hosts` `rh1`
    ON
        `rh1`.`id` = `r1`.`request_host_id`
    INNER JOIN
        `request_uris` `ru1`
    ON
        `ru1`.`id` = `r1`.`request_uri_id`
    INNER JOIN
        `calls` `c1`
    ON
        `c1`.`id` = `r1`.`request_caller_id`
    WHERE
        1=1 {$sql_query['where']}
);

2) 全体の AVG を取得 (300ms)

SELECT COUNT(`id`), MIN(`wt`), MAX(`wt`), AVG(`wt`), MIN(`cpu`), MAX(`cpu`), AVG(`cpu`), MIN(`mu`), MAX(`mu`), AVG(`mu`), MIN(`pmu`), MAX(`pmu`), AVG(`pmu`) FROM `temporary_grouped_data`;

3) 95 パーセンタイル (200ms) を計算する

SELECT `wt` FROM `temporary_grouped_data` ORDER BY `wt` ASC LIMIT 1726, 1;
SELECT `cpu` FROM `temporary_grouped_data` ORDER BY `cpu` ASC LIMIT 1726, 1;
SELECT `mu` FROM `temporary_grouped_data` ORDER BY `mu` ASC LIMIT 1726, 1;
SELECT `pmu` FROM `temporary_grouped_data` ORDER BY `pmu` ASC LIMIT 1726, 1;

4) 計算モード (200ms)

SELECT `wt`, COUNT(`wt`) `quantity` FROM `temporary_grouped_data` GROUP BY `wt` ORDER BY `quantity` DESC LIMIT 1;
SELECT `cpu`, COUNT(`cpu`) `quantity` FROM `temporary_grouped_data` GROUP BY `cpu` ORDER BY `quantity` DESC LIMIT 1;
SELECT `mu`, COUNT(`mu`) `quantity` FROM `temporary_grouped_data` GROUP BY `mu` ORDER BY `quantity` DESC LIMIT 1;
SELECT `pmu`, COUNT(`pmu`) `quantity` FROM `temporary_grouped_data` GROUP BY `pmu` ORDER BY `quantity` DESC LIMIT 1

PHPのやり方。

1) 関連するすべてのレコードを配列に取得します (200ms)。

SELECT
    `r1`.`id`,
    `c1`.`wt`,
    `c1`.`cpu`,
    `c1`.`mu`,
    `c1`.`pmu`
FROM
    `requests` `r1`
INNER JOIN
    `request_hosts` `rh1`
ON
    `rh1`.`id` = `r1`.`request_host_id`
INNER JOIN
    `request_uris` `ru1`
ON
    `ru1`.`id` = `r1`.`request_uri_id`
INNER JOIN
    `calls` `c1`
ON
    `c1`.`id` = `r1`.`request_caller_id`

2) すべての計算を実行します (200ms)。

PHP のアプローチははるかに高速です。PHP を使用してこれらの計算を実行してはならない理由はありますか?

4

2 に答える 2

1

作業を PHP に移すということは、結果セット全体をワイヤ経由で転送しなければならないことを意味し、サイズによっては非常に悪い結果になる可能性があります。また、私はどう考えてもデータベースの人ではありませんが、これらの結果は予想外のものです。データベース バージョンで間違った方法で行っている可能性を調べる必要があります。

于 2012-09-20T14:02:22.110 に答える
0

スピードがすべてではありません。私はそれが属する場所に置きます。

PHPでスケーリングしますか？また、PHP アプローチでは、すべてのデータをデータベースから php に転送する必要があります。RAMのコストなど。データベースが最適化されていない可能性があります。DBのディスクが悪いなどの可能性があります。真剣に、DBに残して、パフォーマンスが悪い理由を確認します。

于 2012-09-20T14:06:59.747 に答える