常用日志参数

经常用到的有错误、快慢查询、二进制等日志

错误日志

1 作用
记录启动\关闭\日常运行过程中,状态信息,警告,错误,排查MySQL运行过程的故障 2 错误日志配置
默认就是开启的: /数据路径下/hostname.err 自定义日志路径和名字:
mysql> select @@log_error;
vim /etc/my.cnf
log_error=/var/log/mysql.log
log_timestamps=system 重启生效
show variables like 'log_error'; 3 日志内容查看
主要关注[ERROR],看上下文

二进制日志

作用

(1)备份恢复必须依赖二进制日志
(2)主从环境必须依赖二进制日志

binlog配置(5.7必须加上server_id)

注意:MySQL默认是没有开启二进制日志的
基础参数查看:
mysql> select @@log_bin;
日志路径及名字
mysql> select @@log_bin_basename;
服务ID号:
mysql> select @@server_id;
二进制日志格式:
mysql> select @@binlog_format;
双一标准之二:
mysql> select @@sync_binlog; 1 创建日志目录
mkdir /data/binlog
chown -R mysql.mysql /data/binlog 2 修改配置文件
vim /etc/my.cnf
server_id=6 # 5.6中,单机可以不需要此参数
log_bin=/data/binlog/mysql-bin # 该目录需要有mysql.mysql权限
binlog_format=row # 5.7的默认配置就是row,可以省略不写
sync_binlog=1 # 每次事务提交都立即刷写binlog到磁盘 3 重启数据库生效
[root@db01 mysql]# /etc/init.d/mysqld restart 4 参数说明
server_id=6
主要是在主从复制过程中必须要加的,但是在5.7版本中,要用以下参数(log_bin),开启binlog日志,即使是单机也是必加的
log_bin=/data/binlog/mysql-bin
(1)开启二进制日志功能
(2)设置二进制日志目录及名称前缀
binlog_format=row

binlog记录了什么

引入
binlog是SQL层的功能。记录的是变更SQL语句,不记录查询语句。 1 记录SQL语句种类
DDL :原封不动的记录当前DDL(statement语句方式)。
DCL :原封不动的记录当前DCL(statement语句方式)。
DML :只记录已经提交的事务DML 2 DML三种记录方式
binlog_format(binlog的记录格式)参数影响
(1)statement(5.6默认)SBR(statement based replication):语句模式原封不动的记录当前DML。
(2)row (5.7默认)RBR(ROW based replication):记录数据行的变化(用户看不懂,需要工具分析)
(3)mixed (混合)MBR(mixed based replication)模式:以上两种模式的混合 3 题
SBR与RBR模式的对比
statement:可读性较高,日志量少,但是不够严谨,有可能出现记录不准确的情况
row :可读性很低,日志量大,足够严谨
update t1 set xxx=xxx where id>1000 -->一共500w行,row模式怎么记录的日志,为什么row模式严谨?
id name intime
insert into t1 values(1,'zs',now())
我们建议使用:row记录模式

event(事件)是什么

1 事件的简介
event是二进制日志的最小记录单元
对于DDL,DCL,一个语句就是一个event
对于DML语句来讲:只记录已提交的事务
例如以下列子,就被分为了4个event
begin; 120 - 340
DML1 340 - 460
DML2 460 - 550
commit; 550 - 760 2 event的组成
三部分构成:
(1) 事件的开始标识
(2) 事件内容
(3) 事件的结束标识
Position:
开始标识: at 194
结束标识: end_log_pos 254
194? 254?
某个事件在binlog中的相对位置号
位置号的作用是什么?
为了方便我们截取事件

日志文件查看

1 查看日志的开启情况
log_bin参数设置的路径,可以找到二进制日志
Master [(none)]>show variables like '%log_bin%';
+---------------------------------+------------------------------+
| Variable_name | Value |
+---------------------------------+------------------------------+
| log_bin | ON |
| log_bin_basename | /data/binlog/mysql-bin |
| log_bin_index | /data/binlog/mysql-bin.index |
| log_bin_trust_function_creators | OFF |
| log_bin_use_v1_row_events | OFF |
| sql_log_bin | ON |
+---------------------------------+------------------------------+
6 rows in set (0.01 sec) 2 查看一共多少个binlog
Master [(none)]>show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 154 |
+------------------+-----------+
1 row in set (0.01 sec) Master [(none)]>flush logs;
Query OK, 0 rows affected (0.03 sec) Master [(none)]>flush logs;
Query OK, 0 rows affected (0.01 sec) Master [(none)]>show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 201 |
| mysql-bin.000002 | 201 |
| mysql-bin.000003 | 154 |
+------------------+-----------+
3 rows in set (0.00 sec) 3 查看mysql正在使用的日志文件
Master [(none)]>show master status;
+------------------+----------+--------------+------------------+-------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------+
| mysql-bin.000003 | 154 | | | |
+------------------+----------+--------------+------------------+-------------------+
Master [(none)]> file:当前MySQL正在使用的文件名
Position:最后一个事件的结束位置号

日志内容查看

1 event查看
Master [binlog]>show binlog events in 'mysql-bin.000003';
+------------------+-----+----------------+-----------+-------------+----------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------------+-----+----------------+-----------+-------------+----------------------------------------+
| mysql-bin.000003 | 4 | Format_desc | 6 | 123 | Server ver: 5.7.20-log, Binlog ver: 4 |
| mysql-bin.000003 | 123 | Previous_gtids | 6 | 154 | |
| mysql-bin.000003 | 154 | Anonymous_Gtid | 6 | 219 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| mysql-bin.000003 | 219 | Query | 6 | 319 | create database binlog |
| mysql-bin.000003 | 319 | Anonymous_Gtid | 6 | 384 | SET @@SESSION.GTID_NEXT= 'ANONYMOUS' |
| mysql-bin.000003 | 384 | Query | 6 | 486 | use `binlog`; create table t1 (id int) |
+------------------+-----+----------------+-----------+-------------+----------------------------------------+ Log_name:binlog文件名
Pos:开始的position *****
Event_type:事件类型
Format_desc:格式描述,每一个日志文件的第一个事件,多用户没有意义,MySQL识别binlog必要信息
Server_id:mysql服务号标识
End_log_pos:事件的结束位置号 *****
Info:事件内容*****
补充:
SHOW BINLOG EVENTS
[IN 'log_name']
[FROM pos]
[LIMIT [offset,] row_count]
[root@db01 binlog]# mysql -e "show binlog events in 'mysql-bin.000004'" |grep drop 2 binlog文件内容详细查看
mysqlbinlog /data/mysql/mysql-bin.000006
mysqlbinlog --base64-output=decode-rows -vvv /data/binlog/mysql-bin.000003
mysqlbinlog -d binlog /data/binlog/mysql-bin.000003
[root@db01 binlog]# mysqlbinlog --start-datetime='2019-05-06 17:00:00' --stop-datetime='2019-05-06 17:01:00' /data/binlog/mysql-bin.000004

基于Position号进行日志截取

核心就是找截取的起点和终点
--start-position=321
--stop-position=513
mysqlbinlog --start-position=219 --stop-position=1347 /data/binlog/mysql-bin.000003 >/tmp/bin.sql 案例: 使用binlog日志进行数据恢复
模拟:
1.
[(none)]>create database binlog charset utf8;
2.
[(none)]>use binlog;
[binlog]>create table t1(id int);
3.
[binlog]>insert into t1 values(1);
[binlog]>commit;
[binlog]>insert into t1 values(2);
[binlog]>commit;
[binlog]>insert into t1 values(3);
[binlog]>commit;
4.
[binlog]>drop database binlog; 恢复:
[(none)]>show master status ;
[(none)]>show binlog events in 'mysql-bin.000004';
[root@db01 binlog]# mysqlbinlog --start-position=1227 --stop-position=2342 /data/binlog/mysql-bin.000004 >/tmp/bin.sql
[(none)]>set sql_Log_bin=0; # 在此会话中,临时将二进制日志关闭,恢复时不会产生新的日志
[(none)]>source /tmp/bin.sql [(none)]>set sql_Log_bin=1; # 恢复完成把参数改回去 案例:
1. 备份策略每天全备,有全量的二进制日志
2. 业务中一共10个库,其中一个被误drop了
3. 需要在其他9个库正常工作过程中进行数据恢复 假如被删除的库为A,
1.恢复昨天A的全备
2.找到A库到今天drop执行之前的所有二进制日志
3.mysqlbinlog工具导出二进制日志为sql
4.执行第3部导入的sql,恢复今天的数据 思考
实验:两个库中的表交叉执行插入语句,然后删除其中一个库,要怎么恢复?
mysqlbinlog -d 指定被删除的库 --start-position=1227 --stop-position=2342 /data/binlog/mysql-bin.000004 >/tmp/bin.sql
另外,如果有多个二进制日志怎么恢复?
一个一个的binlog日志文件导入为sql,然后恢复到数据库

binlog日志的GTID新特性

1 GTID 介绍
5.6版本新加的特性,5.7中做了加强
5.6中不开启,没有这个功能.
5.7中的GTID,即使不开也会有自动生成
SET @@SESSION.GTID_NEXT= 'ANONYMOUS' 2. GTID(Global Transaction ID)
是对于一个已提交事务的编号,并且是一个全局唯一的编号。
它的官方定义如下:
GTID = source_id:transaction_id [root@db01 data]# pwd
/data/mysql/data
[root@db01 data]# ls
auto.cnf db01.pid ib_buffer_pool ibdata1 ib_logfile0 ib_logfile1 ibtmp1 mysql performance_schema school sys test world zabbix
[root@db01 data]# cat auto.cnf
[auto]
server-uuid=a4b648cb-11b8-11ea-8636-000c2990cef0 7E11FA47-31CA-19E1-9E56-C43AA21293967:29 重要参数介绍:
vim /etc/my.cnf
gtid-mode=on # 开启gtid模式
enforce-gtid-consistency=true # 强调gtid一致性
# systemctl restart mysqld # 重启服务 Master [(none)]>create database gtid charset utf8;
Query OK, 1 row affected (0.01 sec) Master [(none)]>show master status ;
+------------------+----------+--------------+------------------+----------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+----------------------------------------+
| mysql-bin.000004 | 326 | | | dff98809-55c3-11e9-a58b-000c2928f5dd:1 |
+------------------+----------+--------------+------------------+----------------------------------------+
1 row in set (0.00 sec) Master [(none)]>use gtid
Database changed
Master [gtid]>create table t1 (id int);
Query OK, 0 rows affected (0.01 sec) Master [gtid]>show master status ;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000004 | 489 | | | dff98809-55c3-11e9-a58b-000c2928f5dd:1-2 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec) Master [gtid]>create table t2 (id int);
Query OK, 0 rows affected (0.01 sec) Master [gtid]>create table t3 (id int);
Query OK, 0 rows affected (0.02 sec) Master [gtid]>show master status ;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000004 | 815 | | | dff98809-55c3-11e9-a58b-000c2928f5dd:1-4 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec) Master [gtid]>begin;
Query OK, 0 rows affected (0.00 sec) Master [gtid]>insert into t1 values(1);
Query OK, 1 row affected (0.00 sec) Master [gtid]>commit;
Query OK, 0 rows affected (0.00 sec) Master [gtid]>show master status ;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000004 | 1068 | | | dff98809-55c3-11e9-a58b-000c2928f5dd:1-5 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec) Master [gtid]>begin;
Query OK, 0 rows affected (0.00 sec) Master [gtid]>insert into t2 values(1);
Query OK, 1 row affected (0.00 sec) Master [gtid]>commit;
Query OK, 0 rows affected (0.01 sec) Master [gtid]>show master status ;
+------------------+----------+--------------+------------------+------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+------------------------------------------+
| mysql-bin.000004 | 1321 | | | dff98809-55c3-11e9-a58b-000c2928f5dd:1-6 |
+------------------+----------+--------------+------------------+------------------------------------------+
1 row in set (0.00 sec) 3. 基于GTID进行查看binlog
具备GTID后,截取查看某些事务日志:
--include-gtids
--exclude-gtids
mysqlbinlog --include-gtids='dff98809-55c3-11e9-a58b-000c2928f5dd:1-6' --exclude-gtids='dff98809-55c3-11e9-a58b-000c2928f5dd:4' /data/binlog/mysql-bin.000004 4 GTID的幂等性
开启GTID后,MySQL恢复Binlog时,重复GTID的事务不会再执行了
就想恢复?怎么办? --skip-gtids
# mysqlbinlog --include-gtids='3ca79ab5-3e4d-11e9-a709-000c293b577e:4' /data/binlog/mysql-bin.000004 >/tmp/binlog.sql
set sql_log_bin=0;
source /tmp/binlog.sql
set sql_log_bin=1;

使用二进制日志恢复数据案例

1 故障环境介绍
创建了一个库db,导入了表t1,t1表中录入了很多数据
一个开发人员,drop database db;
没有备份,日志都在,怎么恢复?
思路:找到建库语句到删库之前所有的日志,进行恢复(开启了GTID模式) 故障案例模拟:
drop database if exists db;
create database db charset utf8;
use db;
create table t1 (id int);
insert into t1 values(1),(2),(3);
insert into t1 values(4),(5),(6);
commit;
update t1 set id=30 where id=3;
commit;
delete from t1 where id=4;
commit;
insert into t1 values(7),(8),(9);
commit;
drop database db;
运行以上语句,模拟故障场景
需求:将数据库恢复到以下状态(提示第13步drop是误操作,其他都是正常操作) 2 有GTID的恢复
2.1查看当前使用的binlog文件
mysql> show master status;
+------------------+----------+--------------+------------------+-------------------------------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB | Executed_Gtid_Set |
+------------------+----------+--------------+------------------+-------------------------------------------+
| mysql-bin.000012 | 1941 | | | a4b648cb-11b8-11ea-8636-000c2990cef0:1-14 |
+------------------+----------+--------------+------------------+-------------------------------------------+
1 row in set (0.00 sec) 2.2查看事件:
mysql> show binlog events in 'mysql-bin.000012';
+------------------+------+----------------+-----------+-------------+-------------------------------------------------------------+
| Log_name | Pos | Event_type | Server_id | End_log_pos | Info |
+------------------+------+----------------+-----------+-------------+-------------------------------------------------------------+
| mysql-bin.000012 | 4 | Format_desc | 6 | 123 | Server ver: 5.7.26-log, Binlog ver: 4
| mysql-bin.000012 | 123 | Previous_gtids | 6 | 194 | a4b648cb-11b8-11ea-8636-000c2990cef0:1-6
| mysql-bin.000012 | 194 | Gtid | 6 | 259 | SET @@SESSION.GTID_NEXT= 'a4b648cb-11b8-11ea-8636-000c2990cef0:7' |
| mysql-bin.000012 | 259 | Query | 6 | 350 | drop database if exists db |
| mysql-bin.000012 | 350 | Gtid | 6 | 415 | SET @@SESSION.GTID_NEXT= 'a4b648cb-11b8-11ea-8636-000c2990cef0:8' |
| mysql-bin.000012 | 415 | Query | 6 | 516 | create database db charset utf8 |
| mysql-bin.000012 | 516 | Gtid | 6 | 581 | SET @@SESSION.GTID_NEXT= 'a4b648cb-11b8-11ea-8636-000c2990cef0:9' |
| mysql-bin.000012 | 581 | Query | 6 | 675 | use `db`; create table t1 (id int) |
| mysql-bin.000012 | 675 | Gtid | 6 | 740 | SET @@SESSION.GTID_NEXT= 'a4b648cb-11b8-11ea-8636-000c2990cef0:10' |
| mysql-bin.000012 | 740 | Query | 6 | 810 | BEGIN |
| mysql-bin.000012 | 810 | Table_map | 6 | 853 | table_id: 110 (db.t1) |
| mysql-bin.000012 | 853 | Write_rows | 6 | 903 | table_id: 110 flags: STMT_END_F |
| mysql-bin.000012 | 903 | Table_map | 6 | 946 | table_id: 110 (db.t1) |
| mysql-bin.000012 | 946 | Write_rows | 6 | 996 | table_id: 110 flags: STMT_END_F |
| mysql-bin.000012 | 996 | Xid | 6 | 1027 | COMMIT /* xid=42 */ |
| mysql-bin.000012 | 1027 | Gtid | 6 | 1092 | SET @@SESSION.GTID_NEXT= 'a4b648cb-11b8-11ea-8636-000c2990cef0:11' |
| mysql-bin.000012 | 1092 | Query | 6 | 1162 | BEGIN |
| mysql-bin.000012 | 1162 | Table_map | 6 | 1205 | table_id: 110 (db.t1) |
| mysql-bin.000012 | 1205 | Update_rows | 6 | 1251 | table_id: 110 flags: STMT_END_F |
| mysql-bin.000012 | 1251 | Xid | 6 | 1282 | COMMIT /* xid=45 */ |
| mysql-bin.000012 | 1282 | Gtid | 6 | 1347 | SET @@SESSION.GTID_NEXT= 'a4b648cb-11b8-11ea-8636-000c2990cef0:12' |
| mysql-bin.000012 | 1347 | Query | 6 | 1417 | BEGIN |
| mysql-bin.000012 | 1417 | Table_map | 6 | 1460 | table_id: 110 (db.t1) |
| mysql-bin.000012 | 1460 | Delete_rows | 6 | 1500 | table_id: 110 flags: STMT_END_F |
| mysql-bin.000012 | 1500 | Xid | 6 | 1531 | COMMIT /* xid=47 */ |
| mysql-bin.000012 | 1531 | Gtid | 6 | 1596 | SET @@SESSION.GTID_NEXT= 'a4b648cb-11b8-11ea-8636-000c2990cef0:13' |
| mysql-bin.000012 | 1596 | Query | 6 | 1666 | BEGIN |
| mysql-bin.000012 | 1666 | Table_map | 6 | 1709 | table_id: 110 (db.t1) |
| mysql-bin.000012 | 1709 | Write_rows | 6 | 1759 | table_id: 110 flags: STMT_END_F |
| mysql-bin.000012 | 1759 | Xid | 6 | 1790 | COMMIT /* xid=49 */ |
| mysql-bin.000012 | 1790 | Gtid | 6 | 1855 | SET @@SESSION.GTID_NEXT= 'a4b648cb-11b8-11ea-8636-000c2990cef0:14' |
| mysql-bin.000012 | 1855 | Query | 6 | 1941 | drop database db
+------------------+------+----------------+-----------+-------------+-----------------------------------------------------------+ 3.截取
[root@db01 binlog]# mysqlbinlog --skip-gtids --include-gtids='a4b648cb-11b8-11ea-8636-000c2990cef0:7:7-13' mysql-bin.000012 >/tmp/bin.sql
参数说明:
--skip-gtids: 跳过gtid检测
--include-gtids:包含的gtid
--exclude-gtids:不包含的gtid --exclude-gtids='3ca79ab5-3e4d-11e9-a709-000c293b577e:8','3ca79ab5-3e4d-11e9-a709-000c293b577e:10' 4.恢复
mysql> set sql_log_bin=0;
mysql> source /tmp/bin.sql;
mysql> set sql_log_bin=0; 5.验证数据
mysql> select * from t1;
+------+
| id |
+------+
| 1 |
| 2 |
| 30 |
| 5 |
| 6 |
| 7 |
| 8 |
| 9 |
+------+
8 rows in set (0.00 sec)

二进制日志其他操作

1 自动清理日志
show variables like '%expire%';
expire_logs_days 0
自动清理时间,是要按照全备周期+1
set global expire_logs_days=8;
永久生效:
my.cnf
expire_logs_days=15;
企业建议,至少保留两个全备周期+1的binlog 2 手工清理
mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000001 | 1052 |
| mysql-bin.000002 | 201 |
| mysql-bin.000003 | 1041 |
| mysql-bin.000004 | 969 |
| mysql-bin.000005 | 969 |
| mysql-bin.000006 | 3149 |
| mysql-bin.000007 | 201 |
| mysql-bin.000008 | 2604 |
| mysql-bin.000009 | 1072 |
| mysql-bin.000010 | 602 |
| mysql-bin.000011 | 1368 |
| mysql-bin.000012 | 1941 |
+------------------+-----------+
12 rows in set (0.01 sec) mysql> PURGE BINARY LOGS TO 'mysql-bin.000010';
Query OK, 0 rows affected (0.00 sec) mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000010 | 602 |
| mysql-bin.000011 | 1368 |
| mysql-bin.000012 | 1941 |
+------------------+-----------+
3 rows in set (0.00 sec) mysql> flush logs;
Query OK, 0 rows affected (0.01 sec) mysql> show binary logs;
+------------------+-----------+
| Log_name | File_size |
+------------------+-----------+
| mysql-bin.000010 | 602 |
| mysql-bin.000011 | 1368 |
| mysql-bin.000012 | 1988 |
| mysql-bin.000013 | 194 |
+------------------+-----------+
4 rows in set (0.00 sec) 注意:不要手工rm binlog文件
1. my.cnf binlog关闭掉,启动数据库
2.把数据库关闭,开启binlog,启动数据库
删除所有binlog,并从000001开始重新记录日志 reset master; 主从关系中,主库执行此操作,主从环境必崩 3 日志是怎么滚动
flush logs;
重启mysql也会自动滚动一个新的
日志文件达到1G大小(max_binlog_size)
max_binlog_size | 1073741824 备份时,加入参数也可以自动滚动

慢日志

1 作用
记录慢SQL语句的日志,定位低效SQL语句的工具日志 2 开启慢日志(默认没开启)
开关:
slow_query_log=1
文件位置及名字
slow_query_log_file=/data/mysql/slow.log
设定慢查询时间:
long_query_time=0.1 # 根据业务的需求更改,默认是10s
没走索引的语句也记录:
log_queries_not_using_indexes vim /etc/my.cnf
slow_query_log=1
slow_query_log_file=/data/mysql/slow.log
long_query_time=0.1
log_queries_not_using_indexes systemctl restart mysqld 3 mysqldumpslow 分析慢日志
mysqldumpslow -s c -t 10 /data/mysql/slow.log # 第三方工具 这个工具很好用
https://www.percona.com/downloads/percona-toolkit/LATEST/
yum install perl-DBI perl-DBD-MySQL perl-Time-HiRes perl-IO-Socket-SSL perl-Digest-MD5
toolkit工具包中的命令:
pt-query-diagest /data/mysql/slow.log
Anemometer基于pt-query-digest将MySQL慢查询可视化 优化案例:
SELECT SUM(invalid_count) as invalid_count, SUM(confirm_count) as confirm_count,SUM(not_confirm_count) as not_confirm_count,SUM(total_count) as total_count
FROM (
select count(att.LogID) as invalid_count, 0 as confirm_count,0 as not_confirm_count,0 as total_count,bp.city_id
FROM builder_project_info as bp
JOIN attendentlog as att ON bp.project_id = att.CompanyID
WHERE att.CompanyID in (SELECT project_id from builder_project_info WHERE city_id = 407) and att.LogTime like "2019-06%" and att.state = 2
GROUP BY bp.city_id
UNION all (
select 0 as invalid_count, count(att.LogID) as confirm_count,0 as not_confirm_count,0 as total_count,bp.city_id
FROM builder_project_info as bp
JOIN attendentlog as att ON bp.project_id = att.CompanyID
WHERE att.CompanyID in (SELECT project_id from builder_project_info WHERE city_id = 407) and att.LogTime like "2019-06%" and att.state = 1
GROUP BY bp.city_id
)
UNION all (
select 0 as invalid_count, 0 as confirm_count,count(att.LogID) as not_confirm_count,0 as total_count,bp.city_id
FROM builder_project_info as bp
JOIN attendentlog as att ON bp.project_id = att.CompanyID
WHERE att.CompanyID in (SELECT project_id from builder_project_info WHERE city_id = 407) and att.LogTime like "2019-06%" and att.state = 0
GROUP BY bp.city_id
)
UNION all (
select 0 as invalid_count, 0 as confirm_count,0 as not_confirm_count,count(att.LogID) as total_count,bp.city_id
FROM builder_project_info as bp
JOIN attendentlog as att ON bp.project_id = att.CompanyID
WHERE att.CompanyID in (SELECT project_id from builder_project_info WHERE city_id = 407) and att.LogTime like "2019-06%"
GROUP BY bp.city_id
)
) as a
GROUP BY a.city_id desc city
desc country show index from city

MySQL-13-日志管理的更多相关文章

  1. MySQl Study学习之--MySQl二进制日志管理

    MySQl Study学习之--MySQl二进制日志管理 MySQL二进制日志(Binary Log)   a.它包括的内容及作用例如以下:     包括了全部更新了数据或者已经潜在更新了数据(比方没 ...

  2. MySQL InnoDB 日志管理机制中的MTR和日志刷盘

    1.MTR(mini-transaction) 在MySQL的 InnoDB日志管理机制中,有一个很重要的概念就是MTR.MTR是InnoDB存储擎中一个很重要的用来保证物理写的完整性和持久性的机制. ...

  3. Go语言学习之13 日志管理平台开发

    主要内容: 1. ElasticSearch介绍与使用2. kibana介绍与使用 1. ElasticSearch安装 详见上节内容2. kibana安装 (1) 下载ES,下载地址:https:/ ...

  4. mysql的日志管理

    日志操作是数据库维护中最重要的手段之一,日志文件会记录MySQL服务器的各种信息,所以当MySQL服务器遭到意外损坏时,不仅可以通过日志文件来查看出错的原因,而且还可以通过日志文件进行数据恢复. MY ...

  5. mysql数据库-日志管理

    MySQL 支持丰富的日志类型 事务日志:transaction log 事务日志的写入类型为"追加",因此其操作为"顺序IO":通常也被称为:预写式日志 wr ...

  6. mysql慢日志管理

    一.日志切割 原理: 1.cp一个慢日志备份 2.清空原理的慢日志 3.写成脚本,每天一切,这样就ok啦 二.查找日志中的慢日志 1.做了日志切割(慢日志文件就小了) 2.查找某个时间的慢日志 日志时 ...

  7. 28.MysQL的日志管理及备份与恢复

    MySQL 索引.事务与存储引擎 目录 MySQL 索引.事务与存储引擎 MySQL 索引 索引的概念 索引的作用及副作用 索引的作用 索引的副作用 创建索引的原则依据 索引的分类和创建 普通索引 唯 ...

  8. MySQL日志管理

    MySQL日志管理 2013年09月26日 ⁄ MySQL ⁄ 共 14266字 ⁄ 评论数 ⁄ 被围观 , views+ 一.日志类型: MySQL有几个不同的日志文件,可以帮助你找出mysqld内 ...

  9. MySQL/MariaDB数据库的各种日志管理

    MySQL/MariaDB数据库的各种日志管理 作者:尹正杰  版权声明:原创作品,谢绝转载!否则将追究法律责任. 一.事务日志 (transaction log) 1>.Innodb事务日志相 ...

  10. MySQL之表日志管理

    MySQL日志管理 mysql日志(默认存放在datadir): 同大多数关系型数据库一样,日志文件是MySQL数据库的重要组成部分.MySQL有几种不同的日志文件,通常包括错误日志文件,二进制日志, ...

随机推荐

  1. MySQL忘记密码怎么办-MySQL修改密码(亲测可用)

    前言: 最近要用到本地的MySQL,结果把密码忘记了. ERROR 1045 (28000): Access denied for user 'root'@'localhost' (using pas ...

  2. Springboot:Springboot+Swagger2集成服务

    Swagger是一个规范和完整的框架,用于生成.描述.调用和可视化 RESTful 风格的 Web 服务.总体目标是使客户端和文件系统作为服务器以同样的速度来更新.文件的方法,参数和模型紧密集成到服务 ...

  3. python二进制读写及特殊码同步

    python对二进制文件的操作需要使用bytes类,直接写入整数是不行的,如果试图使用f.write(123)向文件中以二进制写入123,结果提示参数不是bytes类型. import os impo ...

  4. SpringMVC(9)实现注解式权限验证

    对大部分系统来说都需要权限管理来决定不同用户可以看到哪些内容,那么如何在Spring MVC中实现权限验证呢?当然我们可以继续使用servlet中的过滤器Filter来实现.但借助于Spring MV ...

  5. [转载] 笑话:Developer and product manager

    A man flying in a hot air balloon suddenly realizes he's lost. He reduces height and spots a man dow ...

  6. 使用Hugo框架搭建博客的过程 - 主题配置

    前言 博客部署完成后,恭喜你可以发表第一篇:Hello world!但是LoveIt这么好用的主题,不配置一番可惜了. 基本功能配置 主题配置最好参考已有的配置,比如LoveIt作者写的介绍,还有主题 ...

  7. git研究详解(官网文档)及总结

    前言:git作为新一代的版本控制软件,说实话比svn好用多了,个人见解,关于git的详细介绍及研究,我推荐三个地方 1.git官网上的文档(推荐UC浏览器,比火狐多个英文翻译的功能) 地址为:http ...

  8. VMware中的虚机如何挂载U盘

    1.将U盘插入到宿主机上. 2.在VM Client上,点击宿主机,右键,扫描存储设备(目的是为了发现新USB存储) 3.在需要的虚拟机上编辑配置,添加硬件,添加USB设备(如果不进行以上2个步骤,此 ...

  9. python使用selenium,webdriver自动下载百度网盘内容

    想实现一个自动下载微信公众号分享百度网盘图片链接的爬虫,使用selenium和火狐的webdriver进行完成 1.首先根据自己的浏览器下载相应的webdriver驱动器,python中导入selen ...

  10. 在使用TCP协议进行消息发送时,对消息分帧

    成帧与解析 阅读 <java TCP/IP Socket 编程>第三章笔记 成帧技术(frame)是解决如何在接收端定位消息的首尾位置的问题.在进行数据收发时,必须指定消息接收者如何确定何 ...