できる限り効率性の高い（最小）の型を使用する。MySQL にはディスク領域とメモリを節約できる専用の型がある。 可能な場合は、小さなテーブルの取得には小さな整数型を使用する。たとえば、INTより、25%スペース使用量の少ないMEDIUMINTのほうが適している場合もしばしばあります。

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

MyISAMテーブルでは、可変長カラム(VARCHAR、TEXT、あるいはBLOBなど)がまったくない場合は固定長レコード形式を使用します。これで速度が上りますが、領域の消費も増えます。詳しくは項13.4.3. 「MyISAM テーブルストレージフォーマット」を参照してください。たとえCREATE TABLEオプションROW_FORMAT=FIXEDが使用されたVARCHARカラムがあっても、固定長行が必要な場合のヒントが得られます。

InnoDBはコンパクトストレージフォーマットを使用します。MySQL 5.0.3以前のバージョンでは、InnoDB行は固定サイズカラムにたいしても、カラム数やカラム長さといった冗長な情報を含みます。 デフォルトでは、コンパクトフォーマット(ROW_FORMAT=COMPACT)でテーブルが作成されます。MySQLの旧バージョンにダウングレードをしたい場合、ROW_FORMAT=REDUNDANTで古いフォーマットを要求できます。

コンパクトInnoDBフォーマットはＵＴＦ８データを含むCHARカラムがどのように格納されるかも変更します。最長ＵＴＦ８エンコードキャラクタが3バイトであることを前提に、ROW_FORMAT=REDUNDANTでは、UTF-8 CHAR(N)は3× Nバイトを使用します。多くの言語は主にシングルバイトUTF-8キャラクタを用いてかかれるため、固定保存長はスペースを無駄に使用します。ROW_FORMAT=COMPACTフォーマットでは、 InnoDBはNから3× Nバイトのストレージ可変容量をこれらカラムに割り当てます（必要であればトレールスペースを取り除いて行います）。最小のストレージ長は、ある場合に適切な更新が行われるように、Nバイトとして保持されます。

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

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

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

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