データベースの設定に関する MySQL/MariaDB チュートリアルをランダムに 10 個 Google で検索すると、10 個中 9 個は次のようになります。

データベース somedb を作成します。
'secret' で識別される 'someone'@'localhost' というユーザーを作成します。
somedb.* に対するすべての権限を 'someone'@'localhost' に付与します。
権限をフラッシュします。

どうでしょう？最後のコマンドはまったく必要ありません。

多くのMySQLユーザー（プロのDBAから、テーブルに不要なデータを保存するだけの開発者まで）は、権限を付与した後は権限をフラッシュする必要があると認識しています。しかし、これは決して真実ではありません。

MySQL 3.26まで遡ってみましょう。2001年頃です。地球の地殻はちょうど冷え始めた頃でした。マニュアルにはこう書いてありました。

許可テーブルが直接変更された場合、権限の変更が有効になるように、サーバーに (FLUSH PRIVILEGES を使用して) 許可テーブルを再ロードするように指示する必要があります。

MySQL 4では、「権限の変更が有効になるタイミング」というセクションでこの点が明確にされています。

GRANT、REVOKE、SET PASSWORD などのステートメントを使用して間接的に許可テーブルを変更すると、サーバーはこれらの変更を認識し、許可テーブルをすぐにメモリに再度ロードします。

INSERT、UPDATE、DELETEなどの文を使用して権限テーブルを直接変更した場合、サーバーを再起動するか、テーブルの再ロードを指示するまで、変更内容は権限チェックに反映されません。権限テーブルを手動で再ロードするには、FLUSH PRIVILEGES文を発行するか、mysqladmin flush-privilegesコマンドまたはmysqladmin reloadコマンドを実行してください。

権限テーブルを直接変更した後、リロードを忘れると、サーバーを再起動するまで変更は反映されません。変更が反映されないのはなぜだろうと疑問に思うかもしれません。

この言語は、現在のマニュアルでも（残念ながら最後の一言なしで）継続されます。

ルールは非常にシンプルです:

• GRANTコマンドで権限を付与すると、必要なフラッシュ処理はGRANTによって自動的に行われます。権限をフラッシュする必要はありません。これが標準です。
• 付与テーブルで INSERT、UPDATE、または DELETE を使用する場合 (現在のマニュアルでは「推奨されません」と記載されています)、手動で FLUSH TABLES を実行する必要があります。

つまり、非常に異常なことをしてしまった場合（マニュアルには「してはいけない！」と書いてありますが）、手動で水を流す必要があります。それ以外の場合は、心配する必要はありません。

テーブルを直接変更する必要がある理由はよく分かりませんが、何らかの例外的なケースが存在することは確かで、誰かがコメントで教えてくれるでしょう。