TIMESTAMP は、'YYYY-MM-DD HH:MM:SS' 形式の文字列として返されるようになった（4.0.12 以降では、--new オプションを使用してこの点に関して 4.1 のように動作させることができる）。バージョン 4.0 のように値を数値として返すようにする場合は、TIMESTAMP カラムを取得するときに、それらのカラムに +0 を追加する。

mysql> SELECT ts_col + 0 FROM tbl_name;

TIMESTAMP カラムの桁数指定のサポートは中止された。 たとえば、カラムを TIMESTAMP(10) と宣言しても、(10) は無視される。

これらの変更は、標準 SQL に準拠するために必要であった。今後のバージョンで、さらに変更が行われ（この変更と下位互換性がある）、タイムスタンプ長で秒の小数部の桁数を必要なだけ指定できるようになる予定。

0xFFDF などのバイナリ値は、数値ではなく文字列であると見なされるようになった。これによって、文字列をバイナリ値として入力するのが便利なキャラクタセットのいくつかの問題が修正される。この変更では、バイナリ値を整数として数値比較する場合は、以下のように CAST() を使用する必要がある。

mysql> SELECT CAST(0xFEFF AS UNSIGNED INTEGER) < CAST(0xFF AS UNSIGNED INTEGER);
        -> 0

CAST() を使用しないと、以下のように文字列比較が行われる。

mysql> SELECT 0xFEFF < 0xFF;
        -> 1

数値コンテキストでのバイナリ項目の使用や、= 演算子を使用したバイナリ項目の比較は、従来どおりに機能する（4.0.13 以降では、--new オプションを使用してこの点に関して 4.1 のように動作させることができる）。

DATE 値、DATETIME 値、または TIME 値を生成する関数の場合、クライアントに返される結果は時間の持つ型に修正されている。たとえば、MySQL 4.1 では、以下のような結果が返される。

mysql> SELECT CAST("2001-1-1" as DATETIME);
    -> '2001-01-01 00:00:00'

MySQL 4.0 では、以下のように異なる結果が返される。

mysql> SELECT CAST("2001-1-1" as DATETIME);
    -> '2001-01-01'

AUTO_INCREMENT カラムに DEFAULT 値を指定できなくなった（4.0 では DEFAULT 値は自動的に無視される。4.1 ではエラーが発生する）。

LIMIT は負の引数を受け付けなくなった。 -1 の代わりに 18446744073709551615 を使用する。

SERIALIZE は、sql_mode 変数の有効なオプション値ではなくなった。代わりに、SET TRANSACTION ISOLATION LEVEL SERIALIZABLE を使用する。SERIALIZE は、mysqld の --sql-mode オプションとしても有効ではなくなった。代わりに、--transaction-isolation=SERIALIZABLE を使用する。

すべてのテーブルと文字列カラムがキャラクタセットを持つようになった。 See 章 9. 各国キャラクタセットと Unicode。 キャラクタセット情報は、SHOW CREATE TABLE と mysqldump によって表示される （MySQL バージョン 4.0.6 以降は、新しいダンプファイルを読み取ることはできる。これより前のバージョンは、新しいダンプファイルを読み取ることはできない）。

4.1 では、.frm ファイルで使用されるテーブル定義形式が少し変更されている。4.0.11 以降の MySQL 4.0 バージョンは、この新しい .frm 形式を直接読読み取ることができるが、これより前のバージョンは新しい形式を読み取ることはできない。 バージョン 4.1 のテーブルを 4.0.11 より前のバージョンに移動する必要がある場合は、mysqldump を使用する。 See 項4.9.7. 「mysqldump（テーブル構造とデータのダンプ）」。

同一の Windows マシン上で複数のサーバを実行する場合は、すべてのマシン上で異なる --shared_memory_base_name オプションを使用する必要がある。

UDF 関数へのインタフェースが少し変更された。集約関数 XXX() ごとに xxx_clear() 関数を宣言しなければならなくなった。

前述の変更点をチェックして、使用しているアプリケーションに影響を及ぼすような変更があるかどうかを確認する。

項D.2. 「Changes in release 4.1.x (Alpha)」 を読んで、4.1 で使用できる重要な新機能を確認する。

Windows 上で MySQL サーバを実行する場合は、項2.5.8. 「Windows 上での MySQL のアップグレード」 も参照。

アップグレード後に、パスワードを安全に処理するために必要な、長くなった新しい Password カラムを生成するように権限テーブルを更新する。テーブルの更新は、mysql_fix_privilege_tables を使用して行う。手順については、項2.5.6. 「権限テーブルのアップグレード」 を参照。

4.1 にアップグレードしない。動作は変化しないが、当然ながら 4.1 クライアント/サーバプロトコルによって提供される新機能も一切使用できない（MySQL 4.1 には、プリペアドステートメントや複数結果セットなどの機能を提供する拡張クライアント/サーバプロトコルが組み込まれている）。 See 項11.1.4. 「C API のプリペアドステートメント」。

4.1 にアップグレードして、mysql_fix_privilege_tables スクリプトを実行して、長いパスワードハッシュを格納できるように user テーブルの Password カラムを拡張する。ただし、--old-passwords オプションを指定してサーバを実行して、4.1 より前のバージョンのクライアントが引き続き短いハッシュのクライアントアカウントに接続できるようにして下位互換性を実現する すべてのクライアントが 4.1 にアップグレードされたら、最終的に --old-passwords サーバオプションの使用を中止できるまた、MySQL アカウントのパスワードを、より安全で新しい形式を使用するように変更することもできる

4.1 にアップグレードして、mysql_fix_privilege_tables スクリプトを実行して、user テーブルの Password カラムを拡張する。すべてのクライアントが 4.1 にアップグレードされていることがわかっている場合は、--old-passwords オプションを指定しないでサーバを実行する。代わりに、既存のすべてのアカウントのパスワードを、新しい形式を持つように変更する。純粋な 4.1 インストールが最も安全である。