网上有很多关于pos机交易日志已满请先结算,mysql总结笔记的机交易结算结笔记知识，也有很多人为大家解答关于pos机交易日志已满请先结算的日志问题，今天乐刷官方代理商(www.zypos.cn)为大家整理了关于这方面的已满知识，让我们一起来看下吧!
1、请先pos机交易日志已满请先结算
1 一条SQL查询语句是机交易结算结笔记如何执行的？
mysql逻辑处理架构：4层 （连接，服务，日志引擎，已满存储）
主要：Server层和引擎层
1.1 服务层
连接器：管理连接，请先权限验证
如果用户名密码认证通过，机交易结算结笔记连接器会到权限表里面查出你拥有的日志权限。之后，已满这个连接里面的请先权限判断逻辑，都将依赖于此时读到的机交易结算结笔记权限。查看连接：show processlist ，日志Command 列显示为“Sleep”的已满这一行，就表示现在系统里面有一个空闲连接。客户端如果太长时间没动静，连接器就会自动将它断开。这个时间是由参数 wait_timeout 控制的，默认值是 8 小时。mysql执行过程中使用的内存是管理在连接对象里，所以长连接累积下来，可能导致内存占用太大，被系统强行杀掉（OOM），从现象看就是 MySQL 异常重启了。
解决办法：
1，定期断开长连接。使用一段时间，或者程序里面判断执行过一个占用内存的大查询后，断开连接，之后要查询再重连。
2，如果你用的是 MySQL 5.7 或更新版本，可以在每次执行一个比较大的操作后，通过执行 mysql_reset_connection 来重新初始化连接资源。
查询缓存：mysql8已弃用
执行一个查询请求，先从缓存中查找，没有再到数据库查。
不建议使用查询缓存，因为缓存是失效非常频繁。我们会对表做更新，只要有更新，缓存就失效。而且查询缓存的命中率很低。
配置： query_CACHE_type 设置成 DEMAND，这样对于默认的 SQL 语句都不使用查询缓存。用 SQL_CACHE 显式指定，select SQL_CACHE* from T where ID=10；
分析器：先词法分析，后语法分析。词法分析主要做的是根据mysql的关键字进行验证和解析，而语法分析会在词法解析的基础上进一步做表名和字段名称的验证和解析；
优化器：优化sql，执行计划生成，选择索引
选择索引，选择表的连接顺序。
执行器：操作引擎，返回结果
先判断有没有表执行权限，有才往下执行。根据表的定义，选择引擎。
1.2 引擎层
读取存储层（文件）数据
小结：建立连接，先重缓存中找，没有找到。则依次执行-分析器，优化器，执行器。执行前先做权限检查，最后调用引擎层接口返回数据。
2 一条SQL更新语句是如何执行的？
create table T(ID int primary key, c int);
update T set c=c+1 where ID=2;
1, 更新语句也要经过，连接器，分析器，优化器，执行器，调用引擎更新数据。
2，执行器执行过程：
（1）根据优化器结果，找到主键索引树查找，找到id=2 这一行，如何id=2这一行的数据页在内存中，就直接返回给执行器，否则先从磁盘读入内存。
（2）执行器得到引擎接口给到行数据，把c 加上1 。得到新的一行数据，再调用引擎接口写入。
（3）引擎开启事务，将这行数据更新到内存中，同时也写入到redo log中，此时redo log处于prepare状态，告诉执行器执行完成了。
（4）执行器生成这个操作的binlog日志，写入磁盘
（5）执行器调用引擎的事务提交接口，把刚写入的redo log 改成commit 状态，更新完成。
这个 update 语句的执行流程图，图中浅色框表示是在 InnoDB 内部执行的，深色框表示是在执行器中执行的。
其中涉及到两阶段提交，目的是保证binlog和redo log数据一致性。否则，通过binlog恢复数据，或者扩容，就会出现问题。
2.1 redo log (重做日志）
redo log 日志其实也是写io放在磁盘，但是是顺序写，有优化，效率高。
redo log 独属于innodb引擎，默认一组4个文件，每个文件大小为1GB. 数据结构：循环队列，类比ringBuffer。 循环写，空间会用完。用完后会刷盘。
redo log 是物理日志，只有innodb引擎可以使用的格式，记录的是“某个数据页做了什么修改”。
crash-safe: 有了 redo log，InnoDB 就可以保证即使数据库发生异常重启，之前提交的记录都不会丢失。重启后，自动读取redo log ，恢复数据。
类比：《孔乙己》，餐馆掌柜记账，粉板（redo log , 内存）， 账本 （磁盘）。当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log（粉板）里面，并更新内存，当有一条记录需要更新的时候，InnoDB 引擎就会先把记录写到 redo log（粉板）里面，并更新内存，
WAL 的全称是 Write-Ahead Logging，它的关键点就是先写日志，再写磁盘，也就是先写粉板，等不忙的时候再写账本。
redo log的写入包括两部分内容：一部分是内存中的日志缓冲，称作redo log buffer；另一部分是磁盘日志文件，称作 redo log file。MySQL每执行一条DML语句，先将更新记录写入redo log buffer ，然后再写入redo log file。我们将这种先写日志，再写磁盘的方式称为 WAL(Write-Ahead Logging)技术。
redo log buffer写入redo log file的时机，可以通过 参数innodb_flush_log_at_trx_commit 进行配置，innodb_flush_log_at_trx_commit 这个参数设置成 1 的时候，表示每次事务的 redo log 都直接持久化到磁盘。建议你设置成 1，这样可以保证 MySQL 异常重启之后数据不丢失。
参数为0的时候，称为“延迟写”。事务提交时不会将redo log buffer中日志写入到OS buffer，而是每秒写入OS buffer并调用写入到redo log file中。换句话说，1秒后，实时写和实时刷，只会丢失1秒钟的数据。参数为1 的时候，称为“实时写，实时刷”。事务每次提交都会将redo log buffer中的日志写入OS buffer并保存到redo log file中。其有点是，即使系统崩溃也不会丢失任何数据，缺点也很明显就是每次事务提交都要进行磁盘操作，性能较差。参数为2的时候，称为“实时写，延迟刷”。每次事务提交写入到OS buffer，然后是每秒将日志写入到redo log file。这样性能会好点，缺点是在系统崩溃的时候会丢失1秒中的事务数据。每秒刷一次。这个刷日志的频率由变量 innodb_flush_log_at_timeout 值决定，默认是1秒。要注意，这个刷日志频率和commit动作无关。
redo log记录的是数据页的物理变化，恢复的速度比逻辑日志(binlog)要快。
show GLOBAL VARIABLES like 'innodb_log%'
redo log 磁盘日志文件的总大小（innodb_log_file_size* innodb_log_files_in_group）
2.2 binlog(归档日志）
binlog 属于server层，所有引擎都可以用。追加写，文件写到一定大小后会切换到下一个，并不会覆盖以前的日志。
binlog 是物理日志，记录的是原始逻辑，比如sql语句。
Binlog有3种模式，STATEMENT 格式的话是记sql语句， row格式会记录行的内容，记两条，更新前和更新后都有。mixed 混合模式，默认使用STATEMENT模式保存，STATEMENT模式无法复制的操作使用ROW模式。
# 设置格式
set binlog_format = 'STATEMENT’;
# 关闭binlog
set sql_log_bin=0；
sync_binlog这个参数设置成 1 的时候，表示每次事务的 binlog 都持久化到磁盘。建议你设置成 1，这样可以保证 MySQL 异常重启之后 binlog 不丢失
查看binlog日志列表：show master logs;
生成一个新的binlog日志：FLUSH BINARY LOGS;
查看最后一个binlog日志：show master status;
查看binlog日志的事件：show binlog events ；show binlog events in 'mysql-bin.001333’;
指定查询,从pos点406开始查询：show binlog events in 'mysql-bin.001333’ from 406;
lLog_name：描述存放binlog日志的文件名字。
lPos：描述记日志的开始位置。
lEvent_type：描述类型，例如：查询、插入等。
lServer_id：对应数据库服务器的ID。
lEnd_log_pos：日志结束的位置。
lInfo：执行的SQL语句。
使用mysqlbinlog 命令查看
常用选项：
--start-position=953 起始pos点
--stop-position=1437 结束pos点
--start-datetime="2013-11-29 13:18:54" 起始时间点
--stop-datetime="2013-11-29 13:21:53" 结束时间点
2.3 undo log (回滚日志)
innodb存储引擎对undo的管理采用段的方式。rollback segment称为回滚段，每个回滚段中有1024个undo log segment。
undo log和redo log记录物理日志不一样，它是逻辑日志。可以认为当delete一条记录时，undo log中会记录一条对应的insert记录，反之亦然，当update一条记录时，它记录一条对应相反的update记录。记录事务中数据版本的反向变化。
当执行rollback时，就可以从undo log中的逻辑记录读取到相应的内容并进行回滚。有时候应用到行版本控制的时候，也是通过undo log来实现的：当读取的某一行被其他事务锁定时，它可以从undo log中分析出该行记录以前的数据是什么，从而提供该行版本信息，让用户实现非锁定一致性读取。
如果开启了 innodb_file_per_table ，将放在每个表的.ibd文件中。
通过undo log记录delete和update操作的结果发现：(insert操作无需分析，就是插入行而已)
delete操作实际上不会直接删除，而是将delete对象打上delete flag，标记为删除，最终的删除操作是purge线程完成的。
update分为两种情况：update的列是否是主键列。
如果不是主键列，在undo log中直接反向记录是如何update的。即update是直接进行的。如果是主键列，update分两部执行：先删除该行，再插入一行目标行。存储位置
默认情况下，undo 文件是保存在共享表空间的，也即 ibdatafile 文件中，当数据库中发生一些大的事务性操作的时候，要生成大量的 undo log 信息，这些信息全部保存在共享表空间中，因此共享表空间可能会变得很大，默认情况下，也就是 undo log 使用共享表空间的时候，被“撑大”的共享表空间是不会、也不能自动收缩的。因此，MySQL5.7 之后的“独立 undo 表空间”的配置就显得很有必要了。
2.4 思考
1 redo log 和binlog联系？
通过事务id关联，崩溃恢复时，接受“redolog prepare 并且binlog完整” 的情况
2 mysql 如何恢复数据，比如某天下午两点发现中午十二点有一次误删表，需要找回数据？
（1）找到最近的一次全量备份，从这个备份恢复到临时库；
（2）从备份的时间点开始，将备份的 binlog 依次取出来，重放到中午误删表之前的那个时刻。
（3）把数据从临时库取出来，按需恢复到线上
3 redo log buffer 和 buffer pool 关系？
（1）修改数据，先将数据页读到buffer pool中，进行修改。bufferpool中的page就已经和磁盘中的不一样了，我们称bufferpool中的page为脏页。
（2）脏页存在，系统断电，会不会丢失数据呢？不会，因为记录了redo log日志。
（3）redo log buffer 主要记录的是buffer pool 的页，做了什么改动，所以记的内容不一样。
以上就是关于pos机交易日志已满请先结算,mysql总结笔记的知识，后面我们会继续为大家整理关于pos机交易日志已满请先结算的知识，希望能够帮助到大家！
相关文章：