Innodb Buffer Pool Activity
•Pages Created
•Pages Written
•Pages Read
Innodb Buffer Pool Pages
•Pool Size
•Database Pages
•Free Pages
•Modified Pages
Inoodb File I/O
•File Reads
•Files Writes
•Log Writes
•File Fsyncs
Innodb Pending I/O
•Aio Log Ios
•Aio Sync ios
•Buffer Pool Flushes
•Chkp Writes
•Ibuf Aio Reads
•Log Flushes
•Log Writes
•Normal Aio Reads
•Normal Aio Writes
Innodb Insert Buffer
•Inserts
•Merged
•Merges
Innodb Log
•Log Buffer Size
•Log Bytes Written
•Log Bytes Flushed
•Unflushed Log
Innodb Row Operations
•Rows Read
•Rows Deleted
•Rows Updated
•Rows Inserted
Innodb Semaphores
•Spin Rounds
•Spin Waits
•OS Waits
Innodb Transactions
•Innodb Transactions
•Current Transactions
•History List
•Read Views
MySQL Binary/Relay Logs
•Binlog Cache use
•Binlog Cache Disk Use
•Binary Log Space
•Relay Log Space
MySQL Command Counters
•Questions
•SELECT
•DELETE
•INSERT
•UPDATE
•REPLACE
•LOAD
•DELETE MULTI
•INSERT SELECT
•UPDATE MULTI
•REPLACE SELECT
MySQL Connections
•Max Connections
•Max Used Connections
•Aborted Clients
•Aborted Connects
•Threads Connected
•Connections
MySQL Files and Tables
•Table Cache
•Open Tables
•Open Files
•Opened Tables
MySQL Network Traffic
•Bytes Received
•Bytes Sent
MySQL Processlist
•State Closing Tables
•State Copying to Tmp Table
•State End
•State Freeing Items
•State Init
•State Locked
•State Login
•State Preparing
•State Reading From Net
•State Sending Data
•State Sorting Result
•State Statistics
•State Updating
•State Writing to Net
•State None
•State Other
MySQL Query Cache
•Queries In Cache
•Hits
•Inserts
•Not Cached
•Lowmem Prunes
MySQL Query Cache Memory
•Query Cache Size
•Free Memory
•Total Blocks
•Free Blocks
MySQL Replication
•Slave Running
•Slave Stopped
•Slave Lag
•Slave Open Temp Tables
•Slave Retried Transactions
MySQL Select Types
•Select Full Join
•Select Full Range Join
•Select Range
•Select Range Check
•Select Scan
MySQL Sorts
•Sort Rows
•Sort Range
•Sort Merge Passes
•Sort Scan
MySQL Table Locks
•Table Locks Immediate
•Table Locks Waited
•Slow Queries
MySQL Temporary Objects
•Created Tmp Tables
•Created Tmp Disk Tables
•Created Tmp Files
MySQL Threads
•Thread Cache Size
•Threads Created
MySQL 里经常说到的 WAL技术，也就是先写日志，再写磁盘。
当内存数据页跟磁盘数据页内容不一致的时候，我们成这个内存页为“脏页”。内存数据写入磁盘后，内存和磁盘上的数据页内容就一致了，称为“干净页”。
MySQL 从 内存更新到磁盘的过程，称为刷脏页的过程（flush）。
InnoDB 刷脏页的时机：
往前推进之后，就要把两个点之间的日志对应的所有脏页都 flush 到磁盘上。
这种情况是 InnoDB 要尽量避免的。因为出现这种情况，整个系统都不能接受更新。更新数会跌为0。
那么为什么不能直接淘汰所有的内存，下次请求的时候，再从磁盘读入数据页，然后 拿 redo log 出来应用？这其实也是从性能的角度来考虑的，刷脏页一定写盘，就保证了每个数据页只有两种情况：
这种情况在日常应用中其实是常态。 在InnoDB 中，使用缓冲池 （buffer pool）管理内存，缓冲池中的内存页有三种状态：
刷脏页是常态，所以如果出现以下的情况，都会明明显影响性能：
首先，需要让 InnoDB 正确指导系统的 IO 能力，来控制刷脏页的快慢。
innodb_io_capacity 这个参数，它会告诉 InnoDB 你的磁盘能力，所以尽量设置成磁盘的 IOPS。可以使用 fio 工具来获取。
然后，如果你来设计策略控制刷脏页的速度，会参考哪些因素呢？
这个问题可以这么想，如果刷太慢，会出现什么情况？首先是内存脏页太多，其次是 redo log 写满。
所以，InnoDB 的刷盘速度就是要参考这两个因素：一个是脏页比例，一个是 redo log 写盘速度。
参数 innodb_max_dirty_pages_pct 是脏页比例上限，默认是 75%。InnoDB 会根据当前的脏页比例，计算出一个数字 F1。
InnoDB 写入日志都会有一个序号，当前写入序号跟 checkpoint 对应的序号之间的差值，假设为N。InnoDB 会根据N 计算出 F2.
根据 F1和F2 取其中较大的值为 R，之后引擎就可以按照 Innodb_io_capacity 定义的能力乘以 R% 来控制刷脏页的速度。
MySQL 中有一个机制，刷脏页的时候如果数据页旁边的数据页也是脏页，那么就会一起刷掉，而且这个逻辑是可以蔓延的，所以对于每个相邻的数据页，都会被一起刷。
在 InnoDB 中，innodb_flush_neighbors 参数就是用来控制这个行为的，值为 1 的时候会有上述的“连坐”机制，值为 0 时表示不找邻居，自己刷自己的。
在使用机械硬盘时，这个优化很有意义，可以减少很多随机 IO。如果使用的是 SSD 这种IOPS 比较高的设备，可以设置innodb_flush_neighbors 为0，只刷自己，这个时候 IOPS 往往就不是性能瓶颈了。只刷自己就可以提高刷脏页的速度，减少 SQL 语句的响应时间。
binlog 的写入机制比较简单：事务执行的过程中，先把日志写到 binlog cache，事务提交的时候，再把 binlog cache 写到binlog 文件中。
系统给 binlog cache 分配了一片内存，每个线程一个，参数 binglog_cache_size 用于控制单个线程内 binlog cache 的内存大小，超过就要暂存在磁盘。
事务提交的时候，执行器把 binlog cache 里完整事务写入到 binlog 中，并清空 binlog cache。
write 和 fsync 的时机，是由参数 sync_binlog 控制的：
因此，在出现 IO 瓶颈的场景里，将 sync_binlog 设置成一个比较大的值，可以提升性能。在实际的业务场景中，考虑到丢失日志量的可控性，一般不建议将这个参数设成 0，比较常见的是将其设置为 100~1000 中的某个数值。但是，将 sync_binlog 设置为 N，对应的风险是：如果主机发生异常重启，会丢失最近 N 个事务的 binlog 日志。
事务的执行过程中，生成的 redo log 是要先写到 redo log buffer 的。
redo log 三种状态：
日志写到 redo log buffer 是很快的，write 到 page cache 也差不多，但是持久化到磁盘的速度就慢多了。
InnoDB 提供了 innodb_flush_log_at_trx_commit 参数，取值如下：
InnoDB 有一个后台线程，每隔 1 秒，就会把 redo log buffer 中的日志，调用 write 写到文件系统的 page cache，然后调用 fsync 持久化到磁盘。
组提交 机制
日志逻辑序列号（log sequence number，LSN）是一个单调递增的值，对应 redo log 的一个个写入点。每次写入的长度为 lenght 的 redo log，LSN的值就会加上 length。
LSN 也会写到 InnoDB 的数据页中，来确保数据也不会被多次执行重复的 redo log。
在一组提交里面，组员越多，节约磁盘 IOPS 的效果越好。在并发更新的场景下，第一个事务写完 redo log buffer 以后，接下来这个 fsync 越晚调用，组员可能越多，节约 IOPS 的效果就越好。
WAL机制主要得益于两个方面：
如果你的 MySQL 现在出现了性能瓶颈，而且瓶颈在 IO 上，可以通过哪些方法来提升性能呢？
针对这个问题，可以考虑以下三种方法：
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）