Mysql には 4 種類のログがあります: エラー ログ、一般クエリ ログ、バイナリ ログ、スロー クエリ ログ**
1. エラー ログ
は、Mysql の実行中のエラー、警告、メモおよびその他の情報を記録します。レコードに問題がある場合は、エラー ログを表示できます。
-
Mysql のエラー ログは、デフォルトで Mysql ログ ディレクトリに hostname.err として保存されます。これは次のステートメントで表示できます:
mysql> show variables like "log_error";
+---------------+----------------+
| Variable_name | Value |
+---------------+----------------+
| log_error | /tmp/mysql.log |
+---------------+---------------
ログイン後にコピー
エラー ログ アドレスを変更するには、--log-in を追加します。 /etc/my.cnf error = [filename] を使用して、mysql エラー ログを有効にします。私のものは:
log_error = /tmp/mysql.log
ログイン後にコピー
まず確認してみましょう: tail -f /tmp/mysql.log
bash-3.2# tail -f /tmp/mysql.log
2015-12-23T02:22:41.467311Z 0 [Note] IPv6 is available.
2015-12-23T02:22:41.467324Z 0 [Note] - '::' resolves to '::';
2015-12-23T02:22:41.467350Z 0 [Note] Server socket created on IP: '::'.
2015-12-23T02:22:41.584287Z 0 [Note] Event Scheduler: Loaded 0 events
2015-12-23T02:22:41.584390Z 0 [Note] /usr/local/Cellar/mysql/5.7.9/bin/mysqld: ready for connections.
Version: '5.7.9' socket: '/tmp/mysql.sock' port: 3306 Homebrew
2015-12-23T02:22:42.540786Z 0 [Note] InnoDB: Buffer pool(s) load completed at 151223 10:22:42
151223 10:22:51 mysqld_safe A mysqld process already exists
2015-12-23T02:25:30.984395Z 2 [ERROR] Could not use /tmp/mysql_query.log for logging (error 13 - Permission denied). Turning logging off for the server process. To turn it on again: fix the cause, then either restart the query logging by using "SET GLOBAL GENERAL_LOG=ON" or restart the MySQL server.
2015-12-23T07:28:03.923562Z 0 [Note] InnoDB: page_cleaner: 1000ms intended loop took 61473ms. The settings might not be optimal. (flushed=0 and evicted=0, during the time.)
ログイン後にコピー
情報量が比較的多いので、今は分析しません。 。 。 。もちろん、mysql の設定や接続にエラーがある場合でも、tail -f を使用してログを追跡できます
2. 一般クエリ ログ
は、クエリ、変更、更新の各 SQL を含む、mysql の毎日のログを記録します。 、など。
まず、mysqlでクエリログが有効になっているかどうかを確認します: 「%genera%」のようなグローバル変数を表示します
mysql> show global variables like "%genera%";
+----------------------------------------+----------------------+
| Variable_name | Value |
+----------------------------------------+----------------------+
| auto_generate_certs | ON |
| general_log | OFF |
| general_log_file | /tmp/mysql_query.log |
| sha256_password_auto_generate_rsa_keys | ON |
+----------------------------------------+----------------------+
4 rows in set (0.00 sec)
ログイン後にコピー
ここでログ出力ファイルを構成しました: /tmp/mysql_query.log、ログ機能はオフになっています
-
クエリ ログの出力ファイルは /etc/my.cnf に追加できます general-log-file = [filename]
Mysql が一般ログ ログを開いた後、すべてのクエリ ステートメントを次のように実行できます。一般的なログ ファイルの中の出力をオンにすると、ファイルが非常に大きくなります。デバッグ中はオンにし、通常はオフにすることをお勧めします。ログ機能はオンになっていますが、ログが書き込まれません。mysql のログに問題がある可能性があります。そのため、ログ ファイルは /tmp/mysql_query.log である必要があります。
mysql> set global general_log = on;
Query OK, 0 rows affected (0.01 sec)
mysql> set global general_log = off;
Query OK, 0 rows affected (0.01 sec)
ログイン後にコピー
3. バイナリ ログ バイナリ ログには、主にバックアップ、リカバリ、ロールバック操作に使用される、データベースへの変更を記述するいくつかのイベントが含まれます。など。
1. 関数:
すべての更新されたデータまたは更新される可能性のあるデータ (どの行にも一致しない DELETE など) が含まれます
データベースを更新する各ステートメント (DML) に関する実行時間の情報が含まれます
このオプションを有効にする必要がある場合は、一般的なログ機能をオンにする必要があります
主な目的は、データベースをデータベース障害が発生した時点に復元することです。バイナリ ログにはバックアップ後に行われたすべての更新が含まれるため、可能です
は、スレーブ サーバーに送信されるすべてのステートメントをマスター レプリケーション サーバーにログオンするために使用されます
このオプションを有効にしますデータベース パフォーマンスは 1% 低下しますが、重要なデータベースの場合、整合性のためにパフォーマンスを犠牲にする価値があります
2. 形式
ちょっとした説明: ステートメント モードでは、行モードの欠点がまず解決され、データの各行の変更を記録する必要がないため、binlog ログの量が削減され、I/O とストレージ リソースが節約され、パフォーマンスが向上します。 。なぜなら、マスター上で実行されるステートメントの詳細と、ステートメントが実行されるときのコンテキスト情報を刺激するだけでよいからです。
欠点: ステートメント モードでは、記録された実行ステートメントであるため、これらのステートメントがスレーブ側で正しく実行されるためには、各ステートメントの実行時に関連する情報、つまりコンテキスト情報も記録する必要があります。すべてのステートメントがスレーブ側で実行されたとき、マスター側で実行されたときと同じ結果が得られることを保証します。さらに、mysql は現在急速に発展しているため、多くの新しい機能が常に追加されており、mysql のレプリケーションには多くの課題が生じています。レプリケーションに含まれる内容が複雑になればなるほど、バグが発生しやすくなります。このステートメントでは、主にデータを変更するときに特定の関数が使用される場合に、多くの状況で問題が発生することが判明しています。たとえば、sleep() 関数が一部のバージョンで正しくコピーされない場合です。 last_insert_id() 関数がストアド プロシージャで使用されているため、スレーブとマスターなどで ID の不一致が発生する可能性があります。
3. 配置
log_bin : 用于设定是否启用二进制日志, 由此看是未开启
重点：
You have enabled the binary log, but you haven't provided the mandatory server-id. Please refer to the proper server start-up parameters documentation
说明需要配置一个server-id， 再拿这句话百度，果然是这样。所以在 配置文件/etc/my.cn中添加 server-id = 1，再重启mysql，解决问题。而且在配置的bin-log同级目录增加了mysql-bin.000001 mysql-bin.index mysql-bin.log 三个文件，前两个是自动生成。
参数：
log_bin：设置此参数表示启用binlog功能，并指定路径名称
log_bin_index：设置此参数是指定二进制索引文件的路径与名称
binlog_do_db：此参数表示只记录指定数据库的二进制日志
binlog_ignore_db：此参数表示不记录指定的数据库的二进制日志
max_binlog_cache_size：此参数表示binlog使用的内存最大的尺寸
binlog_cache_size：此参数表示binlog使用的内存大小，可以通过状态变量binlog_cache_use和binlog_cache_disk_use来帮助测试。binlog_cache_use：使用二进制日志缓存的事务数量
binlog_cache_disk_use:使用二进制日志缓存但超过binlog_cache_size值并使用临时文件来保存事务中的语句的事务数量
max_binlog_size：Binlog最大值，最大和默认值是1GB，该设置并不能严格控制Binlog的大小，尤其是Binlog比较靠近最大值而又遇到一个比较大事务时，为了保证事务的完整性，不可能做切换日志的动作，只能将该事务的所有SQL都记录进当前日志，直到事务结束
sync_binlog：这个参数直接影响mysql的性能和完整性
sync_binlog=0：
当事务提交后，Mysql仅仅是将binlog_cache中的数据写入Binlog文件，但不执行fsync之类的磁盘 同步指令通知文件系统将缓存刷新到磁盘，而让Filesystem自行决定什么时候来做同步，这个是性能最好的。
sync_binlog=n，在进行n次事务提交以后，Mysql将执行一次fsync之类的磁盘同步指令，同志文件系统将Binlog文件缓存刷新到磁盘。
Mysql中默认的设置是sync_binlog=0，即不作任何强制性的磁盘刷新指令，这时性能是最好的，但风险也是最大的。一旦系统绷Crash，在文件系统缓存中的所有Binlog信息都会丢失
自动删除binlog
通过binlog参数（expire_logs_days ）来实现mysql自动删除binlog
mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 869 |
+------------------+-----------+
1 row in set (0.00 sec)
mysql> show variables like 'expire_logs_days' ;
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| expire_logs_days | 0 |
+------------------+-------+
1 row in set (0.00 sec)
mysql> ;set global expire_logs_days=3;
ERROR:
No query specified
Query OK, 0 rows affected (0.00 sec)
mysql> show variables like 'expire_logs_days' ;
+------------------+-------+
| Variable_name | Value |
+------------------+-------+
| expire_logs_days | 3 |
+------------------+-------+
1 row in set (0.00 sec)ログイン後にコピー
手工删除binlog
mysql> reset master; //删除master的binlog
mysql> reset slave; //删除slave的中继日志
mysql> purge master logs before '2012-03-30 17:20:00'; //删除指定日期以前的日志索引中binlog日志文件
mysql> purge master logs to 'mysql-bin.000001'; //删除指定日志文件的日志索引中binlog日志文件ログイン後にコピー
或者直接用操作系统命令直接删除
mysql> set sql_log_bin=1/0; //如果用户有super权限，可以启用或禁用当前会话的binlog记录
mysql> show master logs; //查看master的binlog日志
mysql> show binary logs; //查看master的binlog日志
mysql> show master status; //用于提供master二进制日志文件的状态信息
mysql> show slave hosts; //显示当前注册的slave的列表。不以--report-host=slave_name选项为开头的slave不会显示在本列表中ログイン後にコピー
四、Slow Query Log
记录Mysql 慢查询的日志
修改配置文件 /etc/my.cnf
1. Mysql 慢查询配置相关命令：
查看日志功能是否开启：show variables like "%slow%";
mysql> show variables like "%slow%";
+---------------------------+----------------------------------------------------+
| Variable_name | Value |
+---------------------------+----------------------------------------------------+
| log_slow_admin_statements | OFF |
| log_slow_slave_statements | OFF |
| slow_launch_time | 2 |
| slow_query_log | OFF |
| slow_query_log_file | /usr/local/var/mysql/tongkundeMacBook-Pro-slow.log |
+---------------------------+----------------------------------------------------+
ログイン後にコピー
slow_query_log 配置为OFF ， 说明未开启慢日志
打开慢日志功能：set global slow_query_log = on;
mysql> set global slow_query_log = on;
Query OK, 0 rows affected (0.06 sec)
ログイン後にコピー
查看下默认设置的慢查询的时间：show variables like "%long_query%";
mysql> show variables like "%long_query%";
+-----------------+-----------+
| Variable_name | Value |
+-----------------+-----------+
| long_query_time | 10.000000 |
+-----------------+-----------+
ログイン後にコピー
可以看出，默认是10秒，按照这个配置，数据得上n亿才能达到，为了测试我们修改一下
2. 修改Mysql配置文件的方式
3. 测试一下
以上がMysql の 4 種類のログの詳細な紹介の詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
