0

テーブルをチェックしてパフォーマンスを改善するのを手伝うように頼まれました。テーブルは 2.000.000 行の大きなテーブルであり、急速に成長しています。多くの更新/挿入および削除クエリでこのテーブルを使用している多くのユーザーがいます。

パフォーマンスと現実性を改善するための良いアドバイスをくれるかもしれません

テーブル定義は次のとおりです。

CREATE TABLE `計算` (
  `GROUP_LINE_ID` BIGINT(250) NOT NULL DEFAULT '0',
  `GROUP_LINE_PARENT_ID` BIGINT(250) NOT NULL DEFAULT '0',
  `MOEDER_LINE_CODE` BIGINT(250) NOT NULL DEFAULT '0',
  `CALC_ID` BIGINT(250) NOT NULL デフォルト '0',
  `GROUP_ID` BIGINT(250) NOT NULL デフォルト '0',
  `CODE` VARCHAR(250) デフォルト NULL、
  `DESCRIPTION` VARCHAR(250) DEFAULT NULL,
  `RAW_AMOUNT` DECIMAL(50,3) NOT NULL DEFAULT '0.000',
  `AMOUNT` DECIMAL(50,3) NOT NULL DEFAULT '0.000',
  `UNIT` VARCHAR(100) デフォルト NULL、
  `MEN_HOURS` DECIMAL(50,3) NOT NULL DEFAULT '0.000',
  `PRICE_PER_UNIT` DECIMAL(50,3) NOT NULL DEFAULT '0.000',
  `CONTRACTOR_UNIT` DECIMAL(50,3) NOT NULL DEFAULT '0.000',
  `POSTS_PER_UNIT` DECIMAL(50,3) NOT NULL DEFAULT '0.000',
  `SORT_INDEX` BIGINT(250) NOT NULL DEFAULT '0',
  `FACTOR` DECIMAL(50,4) NOT NULL DEFAULT '0.0000',
  `FACTOR_TYPE` INT(2) NOT NULL デフォルト '0',
  `ROUND_AT` DECIMAL(50,2) NOT NULL DEFAULT '0.00',
  `MATERIAL_ID` BIGINT(250) NOT NULL デフォルト '0',
  `MINIMUM` DECIMAL(50,2) NOT NULL DEFAULT '0.00',
  `LINE_TYPE` INT(1) NOT NULL デフォルト '0',
  `ONDERDRUKT` INT(5) NOT NULL デフォルト '0',
  `MARKED` INT(5) NOT NULL DEFAULT '0',
  `IS_TEXT` INT(5) NOT NULL デフォルト '0',
  `BRUTO_PRICE` DECIMAL(20,2) NOT NULL DEFAULT '0.00',
  `AMOUNT_DISCOUNT` DECIMAL(20,3) NOT NULL DEFAULT '0.000',
  `FROM_CONSTRUCTOR` INT(5) NOT NULL デフォルト '0',
  `CHANGE_DATE` DATETIME NOT NULL DEFAULT '0000-00-00 00:00:00',
  `BEREKENING_VALUE` INT(5) NOT NULL デフォルト '0',
  `MAATVOERING_ID` BIGINT(250) NOT NULL DEFAULT '0',
  `KOZIJN_CALC_ID` BIGINT(250) NOT NULL DEFAULT '0',
  `IS_KOZIJN_CALC_TOTALS` INT(5) NOT NULL DEFAULT '0',
  `EAN_CODE` VARCHAR(150) デフォルト NULL、
  `UURLOON_ID` BIGINT(20) NOT NULL DEFAULT '0',
  `ORG_PRICE_PER_UNIT` DECIMAL(50,3) NOT NULL DEFAULT '0.000',
  `ORG_CONTRACTOR_UNIT` DECIMAL(50,3) NOT NULL DEFAULT '0.000',
  `BTWCode` INT(5) NOT NULL DEFAULT '0',
  `IS_CONTROLE_GETAL` INT(5) NOT NULL デフォルト '0',
  `AttentieRegel` INT(5) NOT NULL DEFAULT '0',
  `KozijnSelectionRowId` BIGINT(250) NOT NULL DEFAULT '0',
  `OfferteTekst` テキスト、
  `VerliesFactor` DECIMAL(15,4) NOT NULL DEFAULT '0.0000',
  主キー (`GROUP_LINE_ID`),
  KEY `GROUP_LINE_PARENT_ID` (`GROUP_LINE_PARENT_ID`),
  KEY `MOEDER_LINE_CODE` (`MOEDER_LINE_CODE`),
  KEY `CALC_ID` (`CALC_ID`),
  KEY `GROUP_ID` (`GROUP_ID`),
  KEY `MATERIAL_ID` (`MATERIAL_ID`),
  KEY `MAATVOERING_ID` (`MAATVOERING_ID`),
  KEY `KOZIJN_CALC_ID` (`KOZIJN_CALC_ID`),
  KEY `IS_KOZIJN_CALC_TOTALS` (`IS_KOZIJN_CALC_TOTALS`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;

私の意見では、

  • テーブルエンジンを InnoDB に変更
  • bigint(250) は bigint(10) の int(10) に変更できますか?

アドバイスをお願いします

4

2 に答える 2

2

はい、あなたは正しい..

1.テーブルの主キーは他のすべてのキーの最後に割り当てられることを忘れないでください。主キーのサイズをできるだけ小さくしてください。intで十分だと思います。最大20億のレコードを処理でき、big intは必要ありません

2.key_buffer_size (メモリの最大 25%) を変更します。サーバーに多くの Myisam または myisam テーブルしかない場合は、最大 60 ～ 70% まで増やすことができます。手動キャッシュを試してください。

SET GLOBAL keycache1.key_buffer_size=256*1024;
CACHE INDEX t1,t2 IN keycache1;
LOAD INDEX INTO CACHE t1, t2 IGNORE LEAVES;

(IGNORE LEAVES修飾子により、索引の非リーフ・ノードのブロックのみが再ロードされます)

3.あなたが言及したように、テーブルがより速く成長しているため、テーブルをパーティション分割することをお勧めします。これにより、パフォーマンスが向上します

4.インデックス作成を更新するテーブルを頻繁に分析し、テーブルを最適化し、エラーがある場合はチェックして修復するなどのテーブルメンテナンスタスクを実行します（あなたが言ったように多くの削除があるため、テーブルを頻繁に最適化します）

5. エンジンを変更したくない場合は、(myisam に固有の) delay_key_write 変数をオンにして、テーブルが閉じられた後にキーが更新されるようにします。

6.最良のデータ型を提案するプロシージャanalyse()を実行します

7. myisam を活用するために全文索引を作成し、可能であれば有用な場合にのみ作成する

8. クエリ キャッシュを調べて (クエリ キャッシュ制限をオンデマンドに設定)、スロー クエリ ログを有効にします。

9.テーブルを使用してすべてのクエリを一度調べます（必要に応じて書き直します）

最後に、エンジンを変更したい場合は、テーブル ストレージ エンジンを innodb に変更し、innodb_buffer_pool_size を増やします。

テーブルへのアクセス数が多い場合は、innodb に移行することをお勧めします。これは、myisam がテーブル レベルのロックを実装するため、一部のクエリがスロー クエリ ログに記録されないためです (ロックを取得するのに必要な最初の時間は、実行時間では処理されません)。 MySQL )

于 2013-01-18T10:46:04.837 に答える
1

  1. 最も遅いクエリを見つけるには、 MySQL スロー クエリ ログをオンにします。

  2. それらが選択されている場合は、EXPLAINを介してそれらを実行し、使用されているインデックス (存在する場合) を見つけます。一部のインデックスを複数列のインデックスに変換すると、改善点が見つかる場合があります。違いに関する適切な議論については、複数のインデックスと複数列のインデックスを参照してください。

  3. インデックスが原因で、挿入、更新、および削除が遅くなる可能性があります。使用されていないインデックスを特定して削除する必要があります。残念ながら、最も一般的なクエリを実行する以外に、これを行う簡単な方法はありません。

  4. 大きすぎる列のサイズを小さくすることは良い考えです。

  5. 最近 MyISAM を使用する唯一の理由は、全文検索を行うときです。あなたが提案するように、InnoDBに切り替える必要があります。(ALTER TABLE calculateENGINE = InnoDB;)

  6. これは、結合を避けるために平坦化されたテーブルですか? OfferteTekstこのテーブルに列が必要ですか? それを関連テーブルに抽出することでさえ役立つかもしれませんが、それに対して参加するだけの場合はそうではありません.

于 2013-01-18T10:38:01.013 に答える