できる限り効率性の高い（最小）の型を使用する。MySQL にはディスク領域とメモリを節約できる専用の型がある。

可能な場合は、小さなテーブルの取得には小さな整数型を使用する。たとえば、INT より、MEDIUMINT のほうが適している場合もしばしばある。

できる限り、カラムに NOT NULL を宣言する。これですべてが高速化され、1 カラム当たり 1 ビットを節約できる。アプリケーションで実際に NULL が必要な場合は、必ず使用する必要があるため、注意が必要である。デフォルトですべてのカラムにこれを設定することは避ける。

可変長カラム（VARCHAR、TEXT、BLOB など）がまったくない場合は固定長レコード形式を使用する。これで速度が上がるが、領域の消費も増える。 See 項7.1.2. 「MyISAM テーブル形式」

テーブルのプライマリインデックスを可能な限り短くする。これで、レコードの識別が容易になり効率化が図れる。

テーブルごとに使用するストレージとインデックスの方法を設定する必要がある。 See 章 7. MySQL のテーブル型。

インデックスの作成は必要なものだけに限定する。インデックスは取り出しに優れているが、高速保存が必要な場合は適さない。カラムの組み合わせを使用してテーブルを検索し、テーブルにアクセスする場合がほとんどであれば、インデックスを作成する。インデックスの最初の部分は、最も使用頻度の高いカラムにする必要がある。常に多数のカラムを使用する場合は、より重複しているカラムを先に使用するとインデックスの圧縮を改善できる。

文字列の最初の数文字に、一意のプリフィックスがあるカラムが多い場合は、このプリフィックスのみをインデックス化したほうがよい。MySQL は CHAR 型カラムの部分インデックスをサポートする。短いインデックスの速度が速い理由は、占有ディスク領域が小さいことだけではなく、インデックスキャッシュでのヒットが多くなり、所要ディスクシークが少なくなることにもよる。 See 項5.5.2. 「サーバパラメータのチューニング」。

状況によっては、スキャンの頻度が高いテーブルを 2 つに分割したほうが有利な場合もある。これは特に、動的テーブルで、テーブルスキャンの際に対応するレコードの検索に小さな静的テーブルの使用が可能である場合にあてはまる。