0

私は実際に30列のテーブルを持っています。1 日で、このテーブルは約 3000 の新しいレコードを取得できます。

列のデータは次のようになります。

IMG                                        Name          Phone        etc..

http://www.site.com/images/image.jpg       John Smith    123456789    etc..
http://www.site.com/images/image.jpg       Smith John    987654321    etc..

テーブルのサイズだけでなく、SQL クエリの応答時間も最適化する方法を探しています。私は次のようなことを考えていました:

Column1

http://www.site.com/images/image.jpg|John Smith|123456789|etc..

そして、phpを介して、各値を配列に保存します..

それはより速いでしょうか？

編集

構造の例を挙げると、2 つのテーブルがあるとします。

package
package_content

テーブルの構造は次のとおりpackageです。

id | user_id | package_name | date

テーブルの構造は次のとおりpackage_contentです。

id | package_id | content_name | content_description | content_price | content_color | etc.. > 30columns

問題は、パッケージごとに最大 16 行のコンテンツを取得できることです。例えば ​​：

id   | user_id | package_name | date
260    11        Package 260    2013-7-30 10:05:00

 id | package_id | content_name | content_description | content_price | content_color | etc.. > 30columns
1     260          Content 1      Content 1 desc        58              white           etc..
2     260          Content 2      Content 2 desc        75              black           etc..
3     260          Content 3      Content 3 desc        32              blue            etc..
etc...

次に、phpで私はそのようにします

select * from package
while not EOF {
   show package name, date etc..
   select * from package_content where package_content.package_id = package.id and package.id = package_id
   while not EOF{
       show package_content name, desc, price, color etc...
   }
}
4

2 に答える 2

1

列を結合しないでください。これは役に立たず、最終的に遅くなる可能性さえあります。

クエリを実行する列にはインデックスを使用する必要があります。私は約 30 列の Web サイトを持っており、atm は約 600.000 の結果を持っています。クエリの前に使用EXPLAINする場合は、インデックスが使用されているかどうかを確認する必要があります。同じテーブルで 2 つの値と WHERE を持つ JOIN を取得した場合。JOIN -> WHERE の順に、3 つの列を結合したインデックスを作成する必要があります。同じテーブルに参加する場合、これは別のインデックスとして表示されます。

例えば：

SELECT p.name, p.id, c.name, c2.name 
FROM product p
JOIN category c ON p.cat_id=c.id
JOIN category c2 ON c.parent_id=c2.id AND name='Niels'
WHERE p.filterX='blaat'

カテゴリに複合インデックスが必要です

parent_id,name
AND
id (probably the AI)

製品索引

cat_id
filterX

この簡単なソリューションを使用すると、クエリを NOT DOABLE から 0.10 秒またはそれ以上に最適化できます。

MySQL 5.6 を使用している場合は、INNODB に移行する必要があります。MySQL は JOINS とサブクエリの最適化に優れているためです。また、MySQL はそれらを MEMORY に実行しようとします。これにより、はるかに高速になります。INNODB テーブルのバックアップには特別な注意が必要になる場合があることに注意してください。

また、超高速クエリ用に MEMORY テーブルを作成することも検討できます (それでもインデックスは必要です)。

整数のサイズを 4 (11 文字ではなく 4 バイト) にして最適化することもできます。また、常に VARCHAR 255 を使用するとは限りません。

于 2013-07-30T17:58:17.203 に答える
1

それはより速いでしょうか？絶対にありません。Nameorで検索する必要がある場合は、毎回それらの値を引き出す必要がありますPhone。これらのクエリを最適化することはできません。etc...Column1

テーブルを小さくしたい場合は、いくつかの列を別のテーブルに分割することを検討することをお勧めします。そのオプションを追求したい場合は、構造全体を投稿してください。ただし、列の数は速度にそれほど影響しないことに注意してください。私はそれができることを意味しますが、それはあなたを遅くするもののリストのかなり下にあります.

最後に、1 日あたり 3,000 行は、1 年あたり約 100 万行です。データベースがかなり適切に設計されている場合、MySQL はこれを簡単に処理できます。

補遺: 部分的なテーブル構造に加えて、質問に追加されたサンプル クエリと疑似コード。

この疑似コードは、packageテーブルが一度にすべてクエリされ、一致するpackage_content行が一度に 1 つずつクエリされることを示しています。これは非常にゆっくりとした方法です。を使用する方が良いJOIN：

SELECT
  package.id,
  user_id,
  package_name,
  date,
  package_content.*
FROM package
INNER JOIN package_content on package.id = package_content.id
WHERE whatever
ORDER BY whatever

それはすぐに物事をスピードアップします。

Web ページに表示する場合は、WHERE句を使用して結果を制限してください。1 つの Web ページに 1,000、3,000、または 1,000,000 個のパッケージを見たいと思う人はいないでしょう :)

最後に、前に述べたように、列の数はクエリの最適化にとって大きな問題ではありませんが...

  1. 結果行が非常に広いということは、より多くのデータが MySQL から PHP に送信される必要があることを意味します。

  2. Web ページに 30 列以上の情報を表示しても見栄えが悪いとは思えません。特に、大量の行を読んでいる場合はそうです。

それを念頭に置いて、package_contentクエリで特定の列を選択する方が、SELECT *.

于 2013-07-30T17:57:50.533 に答える