SQL サーバは SQL のさまざまな部分を実装しているので、移植可能な SQL アプリケーションの作成が可能となります。非常に単純な SELECT や INSERT は容易ですが、必要なことが増えれば増えるほど、作成が難しくなります。多数のデータベースを使用しながら素早い速度が要求されるアプリケーションの場合は、さらに難度が上がります。

どのデータベースシステムにも欠点はあります。それはつまり、データベースのすべてに何らかの弱点があります。言い換えると、動作の相違を招くさまざまな設計上の障害があります。

複雑なアプリケーションを移植可能にするには、ともに稼動する必要のある SQL サーバ数を選択する必要があります。MySQL crash-meプログラムを使用すると、データベースサーバの選択に使用できる関数、データ型、制約を調べることができます。現在の crash-meは可能なことすべてのテストを実行できるとは決して言えませんが、約 450 項目のテストが幅広く行われています。 たとえば、crash-meが提供する情報の例として、Infomix や DB2 の使用を可能にするには、18 文字を超えるカラム名は使用できません、といったものがあります。

MySQL ベンチマークと crash-meプログラムはいずれもデータベースへの依存度が非常に低くなっています。これらのプログラムがどのように処理されているかを調べることによって、データベースに依存しないアプリケーションを作成する際に必要なことに関する感覚を得ることができます。ベンチマーク自体は、MySQL ソースディストリビューションの sql-benchディレクトリにあります。 これらはＰｅｒｌで書かれ、ＤＢＩデータベースインターフェースを使用する。DBI の使用それ自体で移植性の問題の1部分を解決できます。これはデータベースから独立したアクセス方法をとるからです。項6.1.4. 「MySQL ベンチマークスィート」を参照してください。

データベースの独立性の獲得を目指す場合は、SQL サーバそれぞれのボトルネックを正しく理解する必要があります。MySQL では、非常に高速にMyISAMレコード（テーブルや行）の取り出しと更新が行われますが、1 つのテーブル上に低速のリーダとライタが混在することに問題があります。異なり、Oracle では、更新直後のレコードがディスクに保存される前にそのレコードにアクセスしようとする際に大きな問題があります。一般にトランザクションデータベースの場合、ログテーブルからのサマリテーブルの生成時は行ロックがほとんど役に立たず、問題が生じやすくなっています。

アプリケーションを実際にデータベース非依存にするには、データ操作に使用する簡単な拡張可能インタフェースを定義する必要があります。 例えば、C++ほとんどのシステムでは C++ が使用できるため、データベースに C++ クラスインタフェースを使用することは道理にかなっています。

あるデータベースに固有の機能を使用する場合（MySQL の REPLACEコマンドなど）は、他の SQL サーバでその機能を実装できるようにするメソッドをコード化する必要があります（ただし低速化します）。低速化しますが、他のサーバで同じ作業を実行できるようにします。

MySQL を使用すると、/*! */構文を使用して MySQL 固有のキーワードをクエリに追加できます。/* */内のコードは、その他の SQL サーバのほとんどでコメントとして処理（無視）されます。コメントの挿入に関する情報は、項8.5. 「コメント構文」を参照してください。

一部の Web アプリケーションのように正確性よりパフォーマンスが重視される場合は、すべての結果をキャッシュするアプリケーションレイヤを作成すると、さらにパフォーマンスを改善できます。一定の期間後に古い結果を '期限切れ' することで、キャッシュを適度に最新の状態に保持できます。これにより、キャッシュを動的に拡大し、通常の状況に戻るまでタイムアウト期限を高速に設定して、高負荷のスパイクを処理するメソッドが提供されます。

この場合、テーブル作成情報にキャッシュの初期サイズと通常時にテーブルがリフレッシュされる頻度に関する情報が組み込まれます。

アプリケーションを実行する代わりにMySQLクエリのキャッシュを使用するのは、効果的です。クエリキャッシュを有効にすることで、クエリ結果が再利用できるかどうかの判断の詳細をサーバに一任します。これによりユーザのアプリケーションは単純化します。項4.13. 「MySQL クエリ キャッシュ」を参照してください。