MySQL :: MySQL 8.0 リファレンスマニュアル :: 12.16 情報関数
BENCHMARK(count,expr) BENCHMARK() 関数は、式 expr を count の回数だけ繰り返し実行します。 MySQL による式の処理速度を計測する際に使用される場合もあります。 NULL や負の繰返し回数などの不適切な引数の場合、結果値は 0 または NULL です。 この使用目的は、mysql クライアント内から、クエリーの実行時間をレポートすることです。 mysql> SELECT BENCHMARK(1000000,AES_ENCRYPT('hello','goodbye')); +---------------------------------------------------+ | BENCHMARK(1000000,AES_ENCRYPT('hello','goodbye')) | +-----------------------------
MySQL :: MySQL 8.0 リファレンスマニュアル :: 25.3.1 トリガーの構文と例
トリガーを作成したり、トリガーを削除したりするには、セクション13.1.22「CREATE TRIGGER ステートメント」およびセクション13.1.34「DROP TRIGGER ステートメント」で説明しているように、CREATE TRIGGER または DROP TRIGGER ステートメントを使用します。 次に、INSERT 操作に対してアクティブ化するトリガーをテーブルに関連付ける簡単な例を示します。 このトリガーは加算器として機能し、テーブルのいずれかのカラムに挿入された値を合計します。 mysql> CREATE TABLE account (acct_num INT, amount DECIMAL(10,2)); Query OK, 0 rows affected (0.03 sec) mysql> CREATE TRIGGER ins_sum BEFORE INSERT O
MySQL :: MySQL 8.0 リファレンスマニュアル :: 15.7.5 InnoDB のデッドロック
デッドロックとは、それぞれが他の必要なロックを保持しているために、異なるトランザクションを続行できない状況です。 両方のトランザクションがリソースが使用可能になるのを待機しているため、保持しているロックは解放されません。 デッドロックは、(UPDATE や SELECT ... FOR UPDATE などのステートメントを使用して) 複数のテーブルの行をトランザクションがロックするときに発生する可能性がありますが、逆の順序で発生します。 デッドロックは、このようなステートメントがインデックスレコードとギャップの範囲をロックし、各トランザクションが一部のロックを取得するけれども、タイミングの問題によりほかを取得しない場合にも発生することがあります。 デッドロックの例については、セクション15.7.5.1「InnoDB デッドロックの例」 を参照してください。 デッドロックの可能性を減らすには
MySQL :: MySQL 8.0 リファレンスマニュアル :: 12.20.3 MySQL での GROUP BY の処理
SQL-92 以前では、選択リスト、HAVING 条件または ORDER BY リストが GROUP BY 句で指定されていない非集計カラムを参照するクエリーは許可されません。 たとえば、このクエリーは、選択リストの非集計 name カラムが GROUP BY に表示されないため、標準 SQL-92 では無効です: SELECT o.custid, c.name, MAX(o.payment) FROM orders AS o, customers AS c WHERE o.custid = c.custid GROUP BY o.custid; クエリーを SQL-92 で有効にするには、選択リストから name カラムを省略するか、GROUP BY 句で名前を指定する必要があります。 SQL:1999 以降では、GROUP BY カラムに機能的に依存している場合、オプション機能 T30
MySQL :: MySQL 8.0 Reference Manual :: B.3.6.2 TEMPORARY Table Problems
Temporary tables created with CREATE TEMPORARY TABLE have the following limitations: TEMPORARY tables are supported only by the InnoDB, MEMORY, MyISAM, and MERGE storage engines. Temporary tables are not supported for NDB Cluster. The SHOW TABLES statement does not list TEMPORARY tables. To rename TEMPORARY tables, RENAME TABLE does not work. Use ALTER TABLE instead: ALTER TABLE old_name RENAME ne
MySQL :: MySQL 5.1 リファレンスマニュアル (オンラインヘルプ) :: 6.3.1.1 TIMESTAMP の特性
TIMESTAMP カラムは DATETIME カラムと同じフォーマットで表示されます。言い換えると、表示幅は 19 文字に決められていて、形式は 'YYYY-MM-DD HH:MM:SS' です。 TIMESTAMP 型の値は、格納するときに現在のタイムゾーンから UTC に変換され、取り出すときに UTC から現在のタイムゾーンに変換されます。(この変換が行われるのは、TIMESTAMP データ型の場合だけで、DATETIME などのほかのデータ型では行われません。)デフォルトでは、接続ごとの現在のタイムゾーンはサーバーの時刻です。タイムゾーンの設定は、MySQL Server Time Zone Supportに説明されているように、接続ごとに行うことができます。タイムゾーン設定が一定であるかぎり、格納した値と同じ値を復帰させることができます。TIMESTAMP 値を格納したあとで、
MySQL :: MySQL 8.0 リファレンスマニュアル :: 5.4.6 サーバーログの保守
セクション5.4「MySQL Server ログ」で説明したように、MySQL Server は実行中のアクティビティーの内容を確認するのに役立ついくつかの異なるログファイルを作成することができます。 ただし、多くのディスクスペースを占有しすぎないようにするために、これらのファイルを定期的にクリーンアップする必要があります。 ロギングを有効にして MySQL を使用しているとき、古いログファイルをときどきバックアップおよび削除して、新しいファイルへのロギングを開始するよう MySQL に指示することが必要な場合があります。 セクション7.2「データベースバックアップ方法」を参照してください。 Linux (Red Hat) インストールでは、mysql-log-rotate スクリプトを使用してログのメンテナンスを行うことができます。 RPM 配布から MySQL をインストールした場合、
MySQL :: MySQL 8.0 リファレンスマニュアル :: 6.2.2 MySQL で提供される権限
MySQL Enterprise Data Masking and De-Identification のインストールまたはアンインストール
MySQL :: MySQL 8.0 リファレンスマニュアル :: 13.1.36 RENAME TABLE ステートメント
SAVEPOINT、ROLLBACK TO SAVEPOINT および RELEASE SAVEPOINT ステートメント
MySQL :: MySQL 8.0 リファレンスマニュアル :: 11.7 データ型のストレージ要件
ディスク上のテーブルデータのストレージ要件は、複数の要因によって異なります。 別々のストレージエンジンは異なる方法でデータ型を表し、ローデータを格納します。 カラムか行全体のどちらかでテーブルデータを圧縮できますが、テーブルまたはカラムのストレージ要件の計算が複雑になります。 ディスク上のストレージレイアウトが違っていても、テーブル行に関する情報を通信および交換する内部 MySQL API は、すべてのストレージエンジンにわたって適用される一貫したデータ構造を使用します。 このセクションでは、データ型の固定サイズ表現を使用するストレージエンジンの内部形式およびサイズを含め、MySQL がサポートするデータ型ごとのストレージ要件に関するガイドラインおよび情報について説明します。 情報はカテゴリまたはストレージエンジンごとに示します。 テーブルの内部表現の最大行サイズは 65,535 バイトで
MySQL :: MySQL 8.0 リファレンスマニュアル :: 9.2 スキーマオブジェクト名
データベース、テーブル、インデックス、カラム、エイリアス、ビュー、ストアドプロシージャ、パーティション、テーブルスペース、リソースグループ、その他のオブジェクト名など、MySQL 内の特定のオブジェクトは識別子と呼ばれます。 このセクションでは、MySQL で使用可能な識別子の構文について説明します。セクション9.2.1「識別子の長さ制限」 は、各タイプの識別子の最大長を示します。セクション9.2.3「識別子の大文字と小文字の区別」 では、大/小文字が区別される識別子のタイプとその条件について説明します。 識別子は引用符で囲むことも囲まないこともあります。 識別子に特殊文字が含まれている場合、または識別子が予約語である場合、その識別子を参照するときは必ず引用符で囲む必要があります。 (例外: 修飾名内でピリオドのあとに続く予約語は識別子である必要があるため、引用符で囲む必要はありません。)
MySQL :: MySQL 5.6 リファレンスマニュアル :: 6.3.2 ユーザーアカウントの追加
アカウントを作成するためのステートメント (CREATE USER や GRANT など) を使用する。これらのステートメントを発行すると、サーバーによって付与テーブルへの適切な変更が行われます。 INSERT、UPDATE、DELETE などのステートメントを使用して、MySQL 付与テーブルを直接操作する。 アカウント作成のステートメントを使用する方が、付与テーブルを直接操作するよりも簡潔で、エラーの発生率も低いため、推奨される方法です。CREATE USER および GRANT については、セクション13.7.1「アカウント管理ステートメント」で説明されています。 アカウントを作成するためのもう 1 つのオプションは、GUI ツール MySQL Workbench を使用する方法です。または、MySQL アカウント管理の機能を提供する使用可能な複数のサードパーティープログラムのいずれ
MySQL AB :: MySQL 5.1 リファレンスマニュアル :: 15 パーティショニング
テーブルのパーティション化は、ウィンドウ関数で使用されるパーティション化とは異なります。 ウィンドウ関数の詳細は、セクション12.21「ウィンドウ関数」 を参照してください。 MySQL 8.0 では、パーティション分割のサポートは InnoDB および NDB ストレージエンジンによって提供されます。 MySQL 8.0 は現在、MyISAM などの InnoDB または NDB 以外のストレージエンジンを使用したテーブルのパーティション化をサポートしていません。 ネイティブパーティション化サポートを提供しないストレージエンジンを使用してパーティションテーブルを作成しようとすると、 ER_CHECK_NOT_IMPLEMENTED で失敗します。 Oracle によって提供される MySQL 8.0 Community バイナリには、InnoDB および NDB ストレージエンジンによっ
MySQL :: MySQL 5.1 リファレンスマニュアル :: 22.2 DECIMAL データ タイプの変更
MySQL の古いバージョン用に書かれたアプリケーションに適合しない可能性のある問題については、このセクション全体で指摘されます。 DECIMAL カラムに対する宣言構文は DECIMAL(M,D) です。MySQL 5.1 における引数値の範囲は次の通りです: M は最大桁数(精度)です。それには1から65までの範囲が含まれています。(古いバージョンの MySQL では、1から254までの範囲が許容されています。) D は少数点（スケール）の右側にある数字の桁数です。それは0から30までの範囲であり、M より広くてはいけません。 M に対する最大値が65である事は、DECIMAL 値に関する計算が65桁まで正確である事を意味します。精度を６５桁とするこの限界は正確値数値リテラルにも適用されるので、このようなリテラルの最大範囲は以前とは異なります。(古いバージョンの MySQL では、１０
MySQL :: MySQL 5.1 リファレンスマニュアル :: 13.5.6.3 AUTO_INCREMENT カラムが InnoDB 内でどのように機能するか
Section Navigation [Toggle] 13.5.6 InnoDB テーブルの作成と利用13.5.6.1 異なる API と共に InnoDB 内でトランザクションをどのように利用するか 13.5.6.2 MyISAM テーブルを InnoDB に変換する 13.5.6.3 AUTO_INCREMENT カラムが InnoDB 内でどのように機能するか 13.5.6.4 FOREIGN KEY 制約 13.5.6.5 InnoDB と MySQL 複製 もし InnoDB テーブルに AUTO_INCREMENT カラムを指定すると、InnoDB データ ディレクトリ内のテーブル ハンドルは、カラムに新しい値を割り当てるのに利用される自動インクリメント カウンタと呼ばれる特別なカウンタを含みます。このカウンタは、ディスク上には格納されず、主メモリ内だけに格納されま
MySQL :: MySQL 4.1 リファレンスマニュアル :: 7.5.10.1 SHOW INNODB STATUS と InnoDB モニタ
バージョン 3.23.42 より、InnoDB の内部状態に関する情報を出力する InnoDB モニタが InnoDB に組み込まれました。 バージョン 3.23.52 および 4.0.3 より、SQL コマンド SHOW INNODB STATUS を使用して、標準 InnoDB モニタの出力を SQL クライアントへ取り込めるようになりました。 このデータは、パフォーマンスチューニングに役立ちます。mysql 対話型 SQL クライアントを使用している場合は、ステートメントの末尾にあるセミコロンを \G に置き換えることで、出力が判読しやすくなります。 SHOW INNODB STATUS\G InnoDB モニタのもう 1 つの使い方として、サーバ mysqld の標準出力に InnoDB モニタから継続的にデータを書き込むことができます（注意: MySQL クライアントからは何も出
MySQL :: MySQL 4.1 リファレンスマニュアル :: 12.1 返されるエラー
任意のホスト言語で MySQL を呼び出したときに発生する可能性があるエラーコードのリストを以下に示します。 名前およびエラーコードの列は、MySQL ソースコードファイル include/mysqld_error.h の定義に対応します。 SQLSTATE の列は、MySQL ソースコードファイル include/sql_state.h の定義に対応します。 SQLSTATE エラーコードは、MySQL バージョン 4.1 を使用する場合にのみ表示されます。SQLSTATE は、X/Open/ANSI/ODBC の動作と互換性を持たせるために追加されました。 各エラーコードに対する説明テキストは、エラーメッセージファイル share/english/errmsg.sys に記述されています。 更新は頻繁に行われるので、上記のソースにエラーコードが追加される可能性があります。 Error:
MySQL :: MySQL 5.1 リファレンスマニュアル :: 17 ストアドプロシージャとファンクション
ストアドルーチン（プロシージャとファンクション）が MySQL 5.1ではサポートされています。ストアドプロシージャはサーバが保存することができるSQLステートメントの組です。これが実行されると、クライアントは各ステートメントを発行し続ける必要がなくなり、代わりにストアドプロシージャを参照します。 MySQL中に保存されているルーチンとその利用に関する一般質問に対する答えは、項A.4. 「MySQL 5.1 FAQ — Stored Procedures」で見ることができます。更に、ストアドルーチンに関する一般的な質問に対する答えについては、項A.6. 「MySQL 5.1 FAQ — Stored Routines, Triggers, and Replication」をご参照ください。 ストアドルーチンが特に有用な幾つかの状況： 複数のクライアントアプリケーションが、複数の言語で書かれ
リリース、障害情報などのサービスのお知らせ
最新の人気エントリーの配信
j次のブックマーク
k前のブックマーク
lあとで読む
eコメント一覧を開く
oページを開く
MySQL :: MySQL 8.0 Reference Manual :: 14.13 Encryption and Compression Functions
MySQL :: MySQL 8.0 リファレンスマニュアル :: 1.7.3.3 無効なデータに対する制約の施行