データベースに最適なバッチサイズの選び方
MySQL、PostgreSQL、SQLite、SQL Serverに対して、行の幅、カラム数、データベース設定に基づいた最適なバッチサイズ選択ガイド。
Batch Sizes
詳細な説明
バッチサイズ選択ガイド
適切なバッチサイズは3つの要素に依存します：データベースエンジン、各行の幅（カラム数と文字列長）、そしてデータベース設定です。
判断マトリックス
| シナリオ | 推奨バッチサイズ |
|---|---|
| SQLite、ワイドテーブル（15カラム以上） | 25-50 |
| SQLite、ナローテーブル（10カラム未満） | 100 |
| MySQL、デフォルト設定 | 100-500 |
MySQL、max_allowed_packet増加済み |
500-1000 |
| PostgreSQL、任意の設定 | 500-1000 |
| SQL Server | 最大1000（ハードリミット） |
制限の計算
SQLiteの場合、制約はSQLITE_MAX_VARIABLE_NUMBER（デフォルト999）です：
max_rows = floor(999 / カラム数)
12カラムのテーブルの場合：floor(999 / 12) = 83行が最大。
MySQLの場合、制約はmax_allowed_packet（デフォルト4MB）です：
estimated_packet_size = 行数 * 平均行バイト数
8カラムで平均50バイトの行 = 400バイト/行。4MB制限では：4,194,304 / 400 = 10,486行。
実践的なヒント
- 控えめに始める: 100から開始し、エラーがなければ増加
- エラーを監視: 「Packet too large」や「too many SQL variables」は、バッチサイズの削減が必要
- ステージングでテスト: 正確なSQLをまずステージングデータベースに対して実行
- トランザクションを検討: バッチをBEGIN/COMMITでラップして一貫性を確保
- ネットワークも重要: リモートデータベースでは大きなバッチの方がネットワークラウンドトリップを節約
ユースケース
DBAがMySQLでBulkインポートが「max_allowed_packet」エラーで時々失敗すると報告した場合。バッチサイズの計算方法を理解することで、設定されたパケットサイズ内に収まる正確な制限を設定できます。