INNODB存储引擎的预写日志方式来保证事务的完整性。这意味着磁盘上的存储的数据页和内存缓冲池中的页是不同步的,对于内粗缓冲中
在innodb存储引擎中,事务日志通过重做(redo)日志文件和innodb存储引擎的日志缓冲(innodb log buffer)来实现;当开始一个事务时,会记录该事务的一个LSN(Log sequence number),当事务执行是,会往innodb存储引擎的缓冲池里插入事务日志,当事务提交是,必须将innodb粗才能引擎的日志缓冲写入磁盘(默认的实现,即innodb_flush_log_at_trx_commit=1),也就是写数据前,需要先写日志,这种方式为预写日志方式(write-ahead logging,WAL).
INNODB存储引擎的预写日志方式来保证事务的完整性。这意味着磁盘上的存储的数据页和内存缓冲池中的页是不同步的,对于内粗缓冲中的页的修改,首先是写入重做日志文件,,然后再写入磁盘。因此是一种异步的方式。可以通过show engine innodb status来观察当前的磁盘和日志的差距;
mysql> create table z(a int,primary key(a)) engine=innodb;
Query OK, 0 rows affected (0.01 sec)
mysql>
mysql> create procedure load_test(count int) begin declare i int unsigned default 0;
-> start transaction;
-> while i
-> set i=i+1;
-> end while;
-> commit;
-> end;
-> $$
Query OK, 0 rows affected (0.05 sec)
mysql> delimiter ;
mysql> show engine innodb status\G;
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
121130 15:41:01 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 12 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 224 1_second, 224 sleeps, 18 10_second, 66 background, 66 flush
srv_master_thread log flush and writes: 228
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 114, signal count 113
Mutex spin waits 6, rounds 180, OS waits 2
RW-shared spins 99, rounds 2970, OS waits 99
RW-excl spins 0, rounds 390, OS waits 13
Spin rounds per wait: 30.00 mutex, 30.00 RW-shared, 390.00 RW-excl
------------------------
LATEST DETECTED DEADLOCK
------------------------
121130 14:17:47
*** (1) TRANSACTION:
TRANSACTION 11F40, ACTIVE 71 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 3 lock struct(s), heap size 320, 2 row lock(s)
MySQL thread id 80, OS thread handle 0x33d62740, query id 4152 localhost root statistics
select * from t3 where a=2 for update
*** (1) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 3132 n bits 80 index `PRIMARY` of table `test`.`t3` trx id 11F40 lock_mode X locks rec but not gap waiting
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 80000002; asc ;;
1: len 6; hex 000000011f35; asc 5;;
2: len 7; hex e00000013a011d; asc : ;;
*** (2) TRANSACTION:
TRANSACTION 11F41, ACTIVE 42 sec starting index read
mysql tables in use 1, locked 1
3 lock struct(s), heap size 320, 2 row lock(s)
MySQL thread id 79, OS thread handle 0x33d62600, query id 4153 localhost root statistics
select * from t3 where a=1 for update
*** (2) HOLDS THE LOCK(S):
RECORD LOCKS space id 0 page no 3132 n bits 80 index `PRIMARY` of table `test`.`t3` trx id 11F41 lock_mode X locks rec but not gap
Record lock, heap no 3 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 80000002; asc ;;
1: len 6; hex 000000011f35; asc 5;;
2: len 7; hex e00000013a011d; asc : ;;
*** (2) WAITING FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 0 page no 3132 n bits 80 index `PRIMARY` of table `test`.`t3` trx id 11F41 lock_mode X locks rec but not gap waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 3; compact format; info bits 0
0: len 4; hex 80000001; asc ;;
1: len 6; hex 000000011f35; asc 5;;
2: len 7; hex e00000013a0110; asc : ;;
*** WE ROLL BACK TRANSACTION (2)
------------
TRANSACTIONS
------------
Trx id counter 11F45
Purge done for trx's n:o History list length 1433
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 11F41, not started
MySQL thread id 79, OS thread handle 0x33d62600, query id 4162 localhost root
show engine innodb status
---TRANSACTION 11F36, not started
MySQL thread id 77, OS thread handle 0x33d61e80, query id 4118 localhost root
---TRANSACTION 11F2B, not started
MySQL thread id 75, OS thread handle 0x33d61d40, query id 4077 192.168.0.69 root
---TRANSACTION 0, not started
MySQL thread id 74, OS thread handle 0x33d61fc0, query id 4070 192.168.0.69 root
---TRANSACTION 0, not started
MySQL thread id 23, OS thread handle 0x33d62380, query id 114 192.168.0.69 root
---TRANSACTION 11F40, ACTIVE 5065 sec
3 lock struct(s), heap size 320, 2 row lock(s)
MySQL thread id 80, OS thread handle 0x33d62740, query id 4152 localhost root
--------
FILE I/O
--------
I/O thread 0 state: waiting for i/o request (insert buffer thread)
I/O thread 1 state: waiting for i/o request (log thread)
I/O thread 2 state: waiting for i/o request (read thread)
I/O thread 3 state: waiting for i/o request (read thread)
I/O thread 4 state: waiting for i/o request (read thread)
I/O thread 5 state: waiting for i/o request (read thread)
I/O thread 6 state: waiting for i/o request (write thread)
I/O thread 7 state: waiting for i/o request (write thread)
I/O thread 8 state: waiting for i/o request (write thread)
I/O thread 9 state: waiting for i/o request (write thread)
Pending normal aio reads: 0 [0, 0, 0, 0] , aio writes: 0 [0, 0, 0, 0] ,
ibuf aio reads: 0, log i/o's: 0, sync i/o's: 0
Pending flushes (fsync) log: 0; buffer pool: 0
691 OS file reads, 1923 OS file writes, 1010 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
-------------------------------------
INSERT BUFFER AND ADAPTIVE HASH INDEX
-------------------------------------
Ibuf: size 1, free list len 0, seg size 2, 0 merges
merged operations:
insert 0, delete mark 0, delete 0
discarded operations:
insert 0, delete mark 0, delete 0
Hash table size 553253, node heap has 6 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 594246629
Log flushed up to 594246629
Last checkpoint at 594246629
0 pending log writes, 0 pending chkp writes
649 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 135987200; in additional pool allocated 0
Dictionary memory allocated 281610
Buffer pool size 8192
Free buffers 4305
Database pages 3881
Old database pages 1418
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 5, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 633, created 3248, written 5875
0.00 reads/s, 0.00 creates/s, 0.00 writes/s
No buffer pool page gets since the last printout
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 3881, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
1 read views open inside InnoDB
Main thread id 869673728, state: waiting for server activity
Number of rows inserted 105750, updated 0, deleted 0, read 59717
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================
1 row in set (0.00 sec)
ERROR:
No query specified
mysql>
mysql> call load_test(10000);
Query OK, 0 rows affected (0.50 sec)

InnoDB uses redologs and undologs to ensure data consistency and reliability. 1.redologs record data page modification to ensure crash recovery and transaction persistence. 2.undologs records the original data value and supports transaction rollback and MVCC.

Key metrics for EXPLAIN commands include type, key, rows, and Extra. 1) The type reflects the access type of the query. The higher the value, the higher the efficiency, such as const is better than ALL. 2) The key displays the index used, and NULL indicates no index. 3) rows estimates the number of scanned rows, affecting query performance. 4) Extra provides additional information, such as Usingfilesort prompts that it needs to be optimized.

Usingtemporary indicates that the need to create temporary tables in MySQL queries, which are commonly found in ORDERBY using DISTINCT, GROUPBY, or non-indexed columns. You can avoid the occurrence of indexes and rewrite queries and improve query performance. Specifically, when Usingtemporary appears in EXPLAIN output, it means that MySQL needs to create temporary tables to handle queries. This usually occurs when: 1) deduplication or grouping when using DISTINCT or GROUPBY; 2) sort when ORDERBY contains non-index columns; 3) use complex subquery or join operations. Optimization methods include: 1) ORDERBY and GROUPB

MySQL/InnoDB supports four transaction isolation levels: ReadUncommitted, ReadCommitted, RepeatableRead and Serializable. 1.ReadUncommitted allows reading of uncommitted data, which may cause dirty reading. 2. ReadCommitted avoids dirty reading, but non-repeatable reading may occur. 3.RepeatableRead is the default level, avoiding dirty reading and non-repeatable reading, but phantom reading may occur. 4. Serializable avoids all concurrency problems but reduces concurrency. Choosing the appropriate isolation level requires balancing data consistency and performance requirements.

MySQL is suitable for web applications and content management systems and is popular for its open source, high performance and ease of use. 1) Compared with PostgreSQL, MySQL performs better in simple queries and high concurrent read operations. 2) Compared with Oracle, MySQL is more popular among small and medium-sized enterprises because of its open source and low cost. 3) Compared with Microsoft SQL Server, MySQL is more suitable for cross-platform applications. 4) Unlike MongoDB, MySQL is more suitable for structured data and transaction processing.

MySQL index cardinality has a significant impact on query performance: 1. High cardinality index can more effectively narrow the data range and improve query efficiency; 2. Low cardinality index may lead to full table scanning and reduce query performance; 3. In joint index, high cardinality sequences should be placed in front to optimize query.

The MySQL learning path includes basic knowledge, core concepts, usage examples, and optimization techniques. 1) Understand basic concepts such as tables, rows, columns, and SQL queries. 2) Learn the definition, working principles and advantages of MySQL. 3) Master basic CRUD operations and advanced usage, such as indexes and stored procedures. 4) Familiar with common error debugging and performance optimization suggestions, such as rational use of indexes and optimization queries. Through these steps, you will have a full grasp of the use and optimization of MySQL.

MySQL's real-world applications include basic database design and complex query optimization. 1) Basic usage: used to store and manage user data, such as inserting, querying, updating and deleting user information. 2) Advanced usage: Handle complex business logic, such as order and inventory management of e-commerce platforms. 3) Performance optimization: Improve performance by rationally using indexes, partition tables and query caches.


Hot AI Tools

Undresser.AI Undress
AI-powered app for creating realistic nude photos

AI Clothes Remover
Online AI tool for removing clothes from photos.

Undress AI Tool
Undress images for free

Clothoff.io
AI clothes remover

AI Hentai Generator
Generate AI Hentai for free.

Hot Article

Hot Tools

Zend Studio 13.0.1
Powerful PHP integrated development environment

DVWA
Damn Vulnerable Web App (DVWA) is a PHP/MySQL web application that is very vulnerable. Its main goals are to be an aid for security professionals to test their skills and tools in a legal environment, to help web developers better understand the process of securing web applications, and to help teachers/students teach/learn in a classroom environment Web application security. The goal of DVWA is to practice some of the most common web vulnerabilities through a simple and straightforward interface, with varying degrees of difficulty. Please note that this software

EditPlus Chinese cracked version
Small size, syntax highlighting, does not support code prompt function

SublimeText3 Mac version
God-level code editing software (SublimeText3)

Safe Exam Browser
Safe Exam Browser is a secure browser environment for taking online exams securely. This software turns any computer into a secure workstation. It controls access to any utility and prevents students from using unauthorized resources.