USER()、CURRENT_USER()、UUID() そして LOAD_FILE() 関数は、 変更のない複製を行うため、スレーブでは確実には機能しません。列ベースのレプリケーションが使用可能な場合はこの限りではありません。詳細は、項5.1.2. 「レプリケーション フォーマット」 を参照してください。

ロギングに関してはコマンド ベースから行ベースに形式移行しないため、混在形式ロギングの初期実行段階の格納関数、トリガそしてこれらを主体とした関数を使用するビューは、混在形式のロギング モードでは確実に複製されません。たとえば、INSERT INTO t SELECT FROM v の v が UUID() を選択するビューの場合、問題を引き起こす可能性があります。この制約は、MySQL 5.1.12 で修正の予定です。

NOW()ではなく、SYSDATE() 関数の場合は、バイナリ ログの SET TIMESTAMP コマンドに影響を受けないこと、そしてコマンド ベースのロギングが使用された場合に非決定性であることから、レプリケーション セーフではありません。行ベースのロギングを使用している場合には、この点の心配はありません。もう一つのオプションには、SYSDATE() が NOW() のエイリアスになることをもたらす --sysdate-is-now オプションでサーバを起動する方法もあります。

以下の制約はステートメント ベースのレプリケーションを行うときに該当します。行ベースのレプリケーションには該当しません。GET_LOCK()、RELEASE_LOCK()、IS_FREE_LOCK()、IS_USED_LOCK() などユーザ レベルでロックを処理する関数の場合には、スレーブはマスタの並列化の前後関係を認識しないまま複製を行います。これにより、スレーブの内容がマスタのものとは異なることになり、これらの関数をマスタのテーブルに挿入するためには使用しないでください。(例： INSERT INTO mytable VALUES(GET_LOCK(...)) のようなコマンドは使わない)