0

オンライン審査員 ( SPOJ.plに似たもの) があり、週末に 3 時間のコンテストを実施し、終了までに約 1000 件近くの提出があります。そして、これらすべての実行を 1 つのテーブル (送信されたコードを含む) に保存します。テーブルの現在の構造は次のとおりです。

+------------+----------+------+-----+---------+----------------+
| Field      | Type     | Null | Key | Default | Extra          |
+------------+----------+------+-----+---------+----------------+
| rid        | int(11)  | NO   | PRI | NULL    | auto_increment |
| pid        | int(11)  | YES  |     | NULL    |                |
| tid        | int(11)  | YES  |     | NULL    |                |
| language   | tinytext | YES  |     | NULL    |                |
| name       | tinytext | YES  |     | NULL    |                |
| code       | longtext | YES  |     | NULL    |                |
| time       | tinytext | YES  |     | NULL    |                |
| result     | tinytext | YES  |     | NULL    |                |
| error      | text     | YES  |     | NULL    |                |
| access     | tinytext | YES  |     | NULL    |                |
| submittime | int(11)  | YES  |     | NULL    |                |
| output     | longtext | YES  |     | NULL    |                |
+------------+----------+------+-----+---------+----------------+

ORDER BYここでの問題は、この中でクエリを実行しているときに句を使用するたびに、テーブル全体をソートしてしまうことです。また、1000 行を超える行があり、それぞれにかなりの量のデータがある場合、かなりの時間がかかります。OPTIMIZEこれは、提出物に変更があったと定期的に表を確認した後であることに注意してください。2 つのオプションがあります。

  1. 約 100 エントリの後にテーブルを分割します。
  2. オーバーヘッドを削減するために、大量のデータ (送信されたコード) をテーブルに値として挿入するのではなく、ファイルとして保存します。

実際にテーブル構造をそのまま維持できる場合、これに対する別の代替/回避策はありますか? 私は本当にここでいくつかの助けを借りることができました. ありがとう。

4

1 に答える 1

0

私のお勧めは、垂直パーティショニングと呼ばれるものを実行することです。つまり、テーブルを異なる列を持つ複数のテーブルに分割します。

この場合、rid、pid、tid、language、name、time、result、access、submittime というすべての小さなデータを含む 1 つのテーブルを作成します。

2 番目のテーブルには、rid、code、error、output が含まれます。

このようにして、最初のテーブルで並べ替えを行い、並べ替え後に他のフィールドを結合できます。コード、エラー、および出力は一緒に表示されるように見えるので、これらをまとめました。

于 2012-08-20T13:38:14.520 に答える