2011-12-05 9 views
2

テーブルには、トランザクションに多くの時間を要する約100万行(物理ディスクのサイズはテキストカラムがあるため、8 GB近く)です。特に、「選択」については、例えば、条件なしでカウントクエリに約12分かかります。つまり、select count(*) from TestPerformanceです。MySQLで巨大なテーブルを照会する

名:TestPerformance

Field  Type Null Key  Default  Extra 

ID  int(11)  NO PRI  null  
TEXT  text  YES   null  
CATEGORY varchar(100) YES  MUL  null  
DDOMAIN  varchar(100) YES   null  
NETWORK  varchar(100) YES   null  
NODE  varchar(100) YES   null  
ENTITY  varchar(100) YES  MUL  null  
SEVERITY int(11)  YES   null  
TTIME  bigint(20) YES   null  
SOURCE  varchar(255) NO MUL  null  
HELPURL  varchar(100) YES   null  
WEBNMS  varchar(100) YES   null  
GROUPNAME varchar(100) YES   null  
OWNERNAME varchar(25)  NO PRI  null  

とインデックスは、私が1ギガバイトにkey_bufferサイズを調整されてきたが、何もパフォーマンスに変化していない

Table   Non_unique Key_name  Seq_in_index Column_name  
TestPerformance  0  PRIMARY   1  ID  
TestPerformance  0  PRIMARY   2  OWNERNAME 
TestPerformance  1  TestPerformance0_ndx 1  ID  
TestPerformance  1  TestPerformance1_ndx 1  OWNERNAME 
TestPerformance  1  TestPerformance_ndx  1  CATEGORY  
TestPerformance  1  TestPerformance_ndx  2  SOURCE  
TestPerformance  1  TestPerformance_ndx1 1  ENTITY  
TestPerformance  1  TestPerformance_ndx2 1  SOURCE 

ある

表のスキーマです。

どのようにデータを削除せずにこのテーブルのトランザクションを高速化できますか?

私はDBエキスパートではありません。テーブルのパフォーマンスを改善するための提案をお寄せください。

+1

問題を引き起こすクエリは表示されませんでした。 –

+0

mysqldumpを使用して、多くの時間を要するクエリを見つけます。 – vikky

+0

'SELECT count(id)from TestPerformance'は時間がかかりますか?必要なフィールドだけを選択してください。 –

答えて

3

どのようにデータを削除せずにこのテーブルのトランザクションを高速化できますか?

百万行は、ではない多くのデータです。 8Gbは大量のデータです。

テキストタイプの列を(1:1の関係で)スペートテーブルに移動します。これらのvarcharテーブルのサイズを、データを保持するために必要な最小サイズに縮小します(または、フィルタリングする必要がないテーブルを他のテーブルに移動することを検討してください)。

プライマリキーのIDは ownernameですか?私はIDがユニークかもしれないと思う。もしそうなら、TestPerformance0_ndxを失う - それは冗長です。実際には、ログを分析し、DBMSが実際にクエリを処理し、それに応じてスキーマを修正するために必要なインデックスを確認する必要があります。

+0

あなたのご意見に感謝します。私はTestPerformance0_ndxとTestPerformance1_ndxを削除しました。テーブルサイズが8 GBから6 GBに減少したのが分かります。パフォーマンスの向上に役立つかどうかをチェックする必要があります。 –

1

クエリでEXPLAINを実行します(ご覧になるには投稿する必要があります)。これは、クエリが使用しようとしているインデックスとフルテーブルスキャンを使用している列を識別するのに役立ちます。

また、count *を選択しないでください。代わりにプライマリレコードをカウントして、インデックスを使用してカウントすることもできます。

+0

@ davidethell説明select * from eventここで、source = 1000およびcategory = 10です。 id | select_type |テーブル|タイプ| possible_keys |キー| key_len | ref |行|エクストラ 1 |シンプル|イベント|すべて| Event_ndx、Event_ndx2 | NULL | NULL | NULL | 808515 |ここでは、 –

+0

@ramachandranを使用して、完全なテーブルスキャンを取得しています。このスキャンは、タイプがALLのExplain結果から確認できます。あなたはソースとカテゴリに関するインデックスを持っていますので、そこで何か助けを得るべきです。最近インデックスを確認するためにテーブルを分析しましたか? – davidethell

関連する問題