mysql 测试
我的test数据库里面有一张表叫做test((Innodb 引擎)表名称这样不好，我这只为了练习)，里面存储了999999条记录，，我导入的时候用的load data，关于上次说的INNODB做一个小小的测试：此次测试的目的是：这样的操作方式会不会引发哈希自适应索引，休眠时间
set profiling=1; select * from test;
过程截图：
mysql> show engine innodb status\G;
*************************** 1. row ***************************
Type: InnoDB
Name:
Status:
=====================================
130321 16:02:59 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 44 seconds
说实在的我不喜欢InnoDB提供的平均值，因为很难取得合理的平均间隔统计值，如果你是写脚本来取得 SHOW INNODB STATUS 结果的话，那么最好取得全局的统计结果，然后取得平均值。当然了，直接查看输出的结果信息也是很有用的。
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 26 1_second, 26 sleeps, 2 10_second, 6 background, 6 flush //mysql 状态切换
srv_master_thread log flush and writes: 26
----------
SEMAPHORES //下一部分显示了信号(Semaphores)相关信息：
----------
OS WAIT ARRAY INFO: reservation count 51, signal count 51
Mutex spin waits 45, rounds 60, OS waits 0
RW-shared spins 67, rounds 1722, OS waits 50
RW-excl spins 3, rounds 30, OS waits 1
Spin rounds per wait: 1.33 mutex, 25.70 RW-shared, 10.00 RW-excl
------------
这段可以分成2个部分。一部分是当前的等待，这部分只是包含了在高并发环境下的全部记录，因此 InnoDB 会频繁回退到系统等待。如果等待是通过自旋锁来解决的话，那么这些信息就就不会显示了。
通过这部分信息，你就会知道系统负载的热点在哪了。不过这需要了解一下源码相关的知识 - 从上面的信息中就可以看出来是哪个源码文件中的哪行(不同的版本结果可能不同)，只是从这里却看不出来任何信息。尽管如此，还是可以从文件名中猜到一些东 西 - 比如本例中，文件名 "buf0buf.ic" 预示着和一些缓冲池争夺有关系。如果想了解更多，就去看源码吧。
还有一些关于等待的更多细节。"lock var" 表示当前的 mutex 对象的值(被锁住 = 1 / 释放 = 0) 值，"waiters flag" 表示当前的等待个数。另外，本例中还可以看到等待状态信息 "wait is ending"，这表示 mutex 已经释放，但是系统调度线程还正在处理。
第二块是事件统计 - "reservation count" 和 "signal count" 显示了 innodb 使用内部同步阵列的活跃程度 - 时间片(slot)分配以及线程信号使用同步阵列的频繁程度。这些统计信息可以用于表示 innodb 回退到系统等待的频率。还有关于系统等待的直接相关信息，可以看到"OS Waits"的互斥信号灯(mutexes)，以及读写锁。这些信息中显示了互斥锁和共享锁。系统等待和 "保留(reservation)" 不完全一样，在回退到用 sync_array 的复杂等待模式前，innodb 会尝试 "输出(yield)" 到系统，希望下一次调度时间对象里命名线程已经释放了。系统等待相对较慢，如果每秒发生了上万次系统等待，则可能会有问题。另一个观察方法是查看系统状态 中的上下文(context)交换频率。
另一块重要的信息是 "spin waits" 和 "spin rounds" 的数量。相较于系统等待，自旋锁是低成本的等待；不过它是一个活跃的等待，会浪费一些cpu资源。因此如果看到大量的自旋等待和自旋轮转，则很显然它浪费 了很多cpu资源。浪费cpu时间和无谓的上下文切换之间可以用 innodb_sync_spin_loops 来平衡。
TRANSACTIONS //事务
------------
Trx id counter 903
Purge done for trx's n:o < 723 undo n:o < 0
History list length 7
LIST OF TRANSACTIONS FOR EACH SESSION:
---TRANSACTION 902, not started
MySQL thread id 2, OS thread handle 0x15e0, query id 33 localhost 127.0.0.1 root
show engine innodb status
---TRANSACTION 900, not started
MySQL thread id 1, OS thread handle 0x1ee8, query id 12 localhost 127.0.0.1 ODBC
--------
FILE I/O //下面这部分显示的是跟IO相关的具体信息：
--------
I/O thread 0 state: wait Windows aio (insert buffer thread)
I/O thread 1 state: wait Windows aio (log thread)
I/O thread 2 state: wait Windows aio (read thread)
I/O thread 3 state: wait Windows aio (read thread)
I/O thread 4 state: wait Windows aio (read thread)
I/O thread 5 state: wait Windows aio (read thread)
I/O thread 6 state: wait Windows aio (write thread)
I/O thread 7 state: wait Windows aio (write thread)
I/O thread 8 state: wait Windows aio (write thread)
I/O thread 9 state: wait Windows aio (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
4516 OS file reads, 7 OS file writes, 7 OS fsyncs
0.00 reads/s, 0 avg bytes/read, 0.00 writes/s, 0.00 fsyncs/s
本部分显示了IO助手线程状态 - 插入缓冲线程，日志线程，读、写线程。它们分别对应插入缓冲合并，异步日志刷新，预读以及刷新脏数据。源自查询的正常读取是由正在运行的查询执行的。在 Unix/Linux平台下，总能看见4个线程，在Windows上可以通过 innodb_file_io_threads 来调整。每个线程准备好之后都能看到其状态：waiting for i/o request 或者正在执行特定的操作。
每 个线程都会显示正在进行的操作数量 - 同时正要执行或者正在执行的操作数量。另外，正在执行的 fsync 操作数量也会显示出来。有写数据时，Innodb需要确保数据最终被写到磁盘上，只是把它们放在系统缓存里是不够的。通常是调用 fsync() 来完成的。如果它的值一直很高，那意味这Innodb可能是处于IO负载较高状态。注意，由线程执行请求引发的IO请求是不计算在内的，因此尽管系统的 IO负载较高，但是它们的值却可能为 0。
接下来显示的是IO操作的平均统计值，它们对于图形显示或者监控很有用。
"16384 avg bytes/read"
是读请求的平均值。随机IO的话，每个页的大小是16K，全表扫描或索引扫描时的预读会导致这个值明显的增加。因此，它体现了预读的效率。
-------------------------------------
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 69257, node heap has 0 buffer(s)
0.00 hash searches/s, 0.00 non-hash searches/s
---
LOG
---
Log sequence number 99058565
Log flushed up to 99058565
Last checkpoint at 99058565
0 pending log writes, 0 pending chkp writes
10 log i/o's done, 0.00 log i/o's/second
----------------------
BUFFER POOL AND MEMORY
----------------------
Total memory allocated 17006592; in additional pool allocated 0
Dictionary memory allocated 24703
Buffer pool size 1024
Free buffers 1
Database pages 1023
Old database pages 357
Modified db pages 0
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 3295, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 4505, created 0, written 1
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: 1023, 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 1940, state: waiting for server activity
Number of rows inserted 0, updated 0, deleted 0, read 1999999
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.02 sec)
上述对INNODB的Status分析来自于rainbowbridg.itpub.net/post/23663/528244。。我是正在努力的学习
