PostgreSQL / MySQL パラメータシート

OSS系データベースの2大製品を1枚にまとめています。設定項目の「概念」は共通で、名前と既定値だけが違うため、PostgreSQL と MySQL のパラメータ名を並記する対応表の形にしました。使う製品の列だけを埋めてください。★核は3枚です。（1）接続と認証設計 … 「繋がらない」の原因がここに集まります。★待ち受けるアドレスの既定はローカルのみで、そのままだと外から繋がりません。接続元の許可は★PostgreSQL は上から順で最初に一致した行、MySQL はより具体的なホストが優先されるため、追加した行が効かないことがあります。さらに接続数の上限はアプリ側の接続プールの合計と合わせないと、DBが正常でも新規接続だけが拒否されます。（2）バックアップと復旧設計 … まるごと取っただけでは取得時点にしか戻れません。任意の時点へ戻すには変更の記録（WALのアーカイブ／バイナリログ）が要ります。★レプリケーションはバックアップではありません。誤削除は複製先へ即座に伝わります。（3）保守設計 … 更新・削除で出た不要領域は自動では戻りません。★整理が止まると表が膨らみ、PostgreSQL では内部の番号が一周した時点で書き込みが止まります。統計情報が古いと実行計画が変わり、突然遅くなります。★既定値は版で変わるため、公式ドキュメントで裏が取れたものだけを記載し、それ以外は「要確認」と明記しています。

★文字コードと照合順序は後から変えられません。作成時に決め、復元先とも一致させてください。★待ち受けるアドレスの既定はローカルのみです。外から使うなら必ず変えてください（変更に再起動が要ります）。★接続元の許可は評価のされ方が製品で違います。PostgreSQL は追加した行が下にあると効きません。MySQL は広い指定を足しても狭い指定が勝ちます。★接続数はアプリの台数 × プールの上限 ＋ 保守用の余裕 で計算してください。上限まで使い切ると管理者も入れなくなります。★接続元を増やしたら、DB側の許可とOSのファイアウォールの両方に足してください。片方だけだと増やしたサーバーからだけ繋がりません。★任意の時点へ戻すには、まるごとの取得と変更の記録の両方が要ります。記録は溜まるので、取り始めたら消す設計も同時にしてください。領域が尽きるとDBが止まります。★レプリケーションはバックアップではありません。複製とバックアップの両方を用意してください。★自動整理を「重いから」で止めないでください。止めるのではなく、しきい値と並列度を調整して追いつかせてください。★大量に投入した直後は統計情報を明示的に更新してください。「昨日まで速かったのに」の多くはこれです。パスワード・接続情報は書かず「別紙参照」としてください。