mtime		文件内容上次修改时间
atime		文件被读取或访问的时间
ctime		文件状态变化时间

mtime 和 atime 的含义都是很容易理解的，而 ctime 则需要更多的解释。由于 inode 维护着每个文件上的元数据，因此，如果与文件有关的元数据发生变化，则 inode 数据也将变化。这可能是由一系列操作引起的，包括创建到文件的符号链接、更改文件权限或移动了文件等。由于在这些情况下，文件内容不会被读取或修改，因此 mtime 和 atime 不会改变，但 ctime 将发生变化。

这些时间选项都需要与一个值 n 结合使用，指定为 -n、n 或 +n。

N * 24
+1	表示	1 * 24 +24小时以外..
+0	表示	0 * 24 +24小时以外
1	表示	1 * 24 + 24 到 24 之间..
0	表示	0 * 24 + 24 到 0 之间..
-1	表示	0 * 24 +24 内,甚至为未来时间...

1.当前时间24小时—当前时间（昨天-今天）
#find . -mtime 0
2.当前时间48小时前–当前时间24小时前(前天-昨天)
#find . -mtime 1
3.当前时间48小时前（2天前）
#find . -mtime +1
4.当前时间24小时–当前时间（昨天-今天）
#find . -mtime -1

————————————————————————————————————————-

Table：显示这一步所访问的数据库中的表的名称。

Type：告诉我们对表使用的访问方式，主要包含如下集中类型。
(1)all：全表扫描。
(2)const：读常量，最多只会有一条记录匹配，由于是常量，实际上只须要读一次。
(3)eq_ref：最多只会有一条匹配结果，一般是通过主键或唯一键索引来访问。
(4)fulltext：进行全文索引检索。
(5)index：全索引扫描。
(6)index_merge：查询中同时使用两个（或更多）索引，然后对索引结果进行合并（merge），再读取表数据。
(7)index_subquery：子查询中的返回结果字段组合是一个索引（或索引组合），但不是一个主键或唯一索引。
(8)rang：索引范围扫描。
(9)ref：Join语句中被驱动表索引引用的查询。
(10)ref_or_null：与ref的唯一区别就是在使用索引引用的查询之外再增加一个空值的查询。
(11)system：系统表，表中只有一行数据。
(12)unique_subquery：子查询中的返回结果字段组合是主键或唯一约束。

Possible_keys：该查询可以利用的索引。如果没有任何索引可以使用，就会显示成null，这项内容对优化索引时的调整非常重要。

Key：mysql Query Optimizer 从 possible_keys 中所选择使用的索引。

Key_len：被选中使用索引的索引键长度。

Ref：列出是通过常量（const），还是某个表的某个字段（如果是join）来过滤（通过key）的。

Rows：mysql Query Optimizer 通过系统收集的统计信息估算出来的结果集记录条数。

Extra：查询中每一步实现的额外细节信息，主要会是以下内容。
(1)Distinct：查找distinct 值，当mysql找到了第一条匹配的结果时，将停止该值的查询，转为后面其他值查询。
(2)Full scan on NULL key：子查询中的一种优化方式，主要在遇到无法通过索引访问null值的使用。
(3)Impossible WHERE noticed after reading const tables：MySQL Query Optimizer 通过收集到的统计信息判断出不可能存在结果。
(4)No tables：Query 语句中使用 FROM DUAL或不包含任何 FROM子句。
(5)Not exists：在某些左连接中，MySQL Query Optimizer通过改变原有 Query 的组成而使用的优化方法，可以部分减少数据访问次数。
(6)Range checked for each record (index map: N)：通过 MySQL 官方手册的描述，当 MySQL Query Optimizer 没有发现好的可以使用的索引时，如果发现前面表的列值已知，部分索引可以使用。对前面表的每个行组合，MySQL检查是否可以使用range或index_merge访问方法来索取行。
(7)SELECT tables optimized away：当我们使用某些聚合函数来访问存在索引的某个字段时，MySQL Query Optimizer 会通过索引直接一次定位到所需的数据行完成整个查询。当然，前提是在 Query 中不能有 GROUP BY 操作。如使用MIN()或MAX()的时候。
(8)Using filesort：当Query 中包含 ORDER BY 操作，而且无法利用索引完成排序操作的时候，MySQL Query Optimizer 不得不选择相应的排序算法来实现。
(9)Using index：所需数据只需在 Index 即可全部获得，不须要再到表中取数据。
(10)Using index for group-by：数据访问和 Using index 一样，所需数据只须要读取索引，当Query 中使用GROUP BY或DISTINCT 子句时，如果分组字段也在索引中，Extra中的信息就会是 Using index for group-by。
(11)Using temporary：当 MySQL 在某些操作中必须使用临时表时，在 Extra 信息中就会出现Using temporary 。主要常见于 GROUP BY 和 ORDER BY 等操作中。
(12)Using where：如果不读取表的所有数据，或不是仅仅通过索引就可以获取所有需要的数据，则会出现 Using where 信息。
(13)Using where with pushed condition：这是一个仅仅在 NDBCluster存储引擎中才会出现的信息，而且还须要通过打开 Condition Pushdown 优化功能才可能被使用。控制参数为 engine_condition_pushdown 。

● QPS（每秒Query 量）：这里的QPS 实际上是指mysql Server 每秒执行的Query总量，在MySQL 5.1.30 及以下版本可以通过Questions 状态值每秒内的变化量来近似表示，而从MySQL 5.1.31 开始，则可以通过Queries 来表示。Queries 是在MySQL 5.1.31 才新增的状态变量。主要解决的问题就是Questions 状态变量并没有记录存储过程中所执行的Query（当然，在无存储过程的老版本MySQL 中则不存在这个区别），而Queries 状态变量则会记录。二者获取方式：QPS = Questions(or Queries) / Seconds

获取所需状态变量值：

SHOW GLOBAL  STATUS LIKE  ’Questions’

SHOW GLOBAL  STATUS LIKE  ’Queries’

这里的Seconds 是指累计出上述两个状态变量值的时间长度，后面用到的地方也代表同样的意思。

● TPS（每秒事务量）： 在MySQL Server 中并没有直接事务计数器，我们只能通过回滚和提交计数器来计算出系统的事务量。所以，我们需要通过以下方式来得到客户端应用程序所请求的TPS 值：TPS = (Com_commit + Com_rollback) / Seconds如果我们还使用了分布式事务，那么还需要将Com_xa_commit 和Com_xa_rollback 两个状态变量的值加上。● Key Buffer 命中率：Key Buffer 命中率代表了MyISAM 类型表的索引的Cache命中率。该命中率的大小将直接影响MyISAM 类型表的读写性能。Key Buffer 命中率实际上包括读命中率和写命中率两种，MySQL 中并没有直接给出这两个命中率的值，但是可以通过如下方式计算出来：

key_buffer_read_hits = (1 – Key_reads / Key_read_requests) * 100%

key_buffer_write_hits= (1 – Key_writes / Key_write_requests) * 100%

获取所需状态变量值：

sky@localhost : (none) 07:44:10> SHOW /*!50000 GLOBAL */ STATUS-> LIKE ‘Key%’;

+————————+——-+

| Variable_name | Value |

+————————+——-+

| Key_read_requests | 10 |

| Key_reads | 4 |

| Key_write_requests | 0 |

| Key_writes | 0 |

+————————+——-+

通过这两个计算公式，我们很容易就可以得出系统当前Key Buffer 的使用情况

● Innodb Buffer 命中率：这里Innodb Buffer 所指的是innodb_buffer_pool，也就是用来缓存Innodb 类型表的数据和索引的内存空间。类似Key buffer，我们同样可以根据MySQL Server 提供的相应状态值计算出其命中率：

innodb_buffer_read_hits=(1-Innodb_buffer_pool_reads/Innodb_buffer_pool_read_requests) * 100%

获取所需状态变量值：

sky@localhost : (none) 08:25:14> SHOW /*!50000 GLOBAL*/ STATUS-> LIKE ‘Innodb_buffer_pool_read%’;

+———————————–+——-+

| Variable_name | Value |

+———————————–+——-+

| Innodb_buffer_pool_read_requests | 5367 |

| Innodb_buffer_pool_reads | 507 |

+———————————–+——-+

● Query Cache 命中率：如果我们使用了Query Cache，那么对Query Cache 命中率进行监控也是有必要的，因为他可能告诉我们是否在正确的使用Query Cache。Query Cache 命中率的计算方式如下：

Query_cache_hits= (Qcache_hits / (Qcache_hits + Qcache_inserts)) * 100%

获取所需状态变量值：

sky@localhost : (none) 08:32:01> SHOW /*!50000 GLOBAL*/ STATUS-> LIKE ‘Qcache%’;

+————————-+——-+|

Variable_name | Value |

+————————-+——-+

| Qcache_hits | 0 |

| Qcache_inserts | 0 |

+————————-+——-+

● Table Cache 状态量：Table Cache 的当前状态量可以帮助我们判断系统参数table_open_cache 的设置是否合理。如果状态变量Open_tables 与Opened_tables 之间的比率过低，则代表Table Cache 设置过小，个人认为该值处于80% 左右比较合适。注意，这个值并不是准确的Table Cache 命中率。获取所需状态变量值：

sky@localhost : (none) 08:52:00> SHOW /*!50000 GLOBAL*/ STATUS-> LIKE ‘Open%’;

+————————–+——-+

| Variable_name | Value |

+————————–+——-+

| Open_tables | 51 |

| Opened_tables | 61 |

+————————–+——-+

● Thread Cache 命中率：Thread Cache 命中率能够直接反应出我们的系统参数thread_cache_size 设置的是否合理。一个合理的thread_cache_size 参数能够节约大量创建新连接时所需要消耗的资源。Thread Cache 命中率计算方式如下：

Thread_cache_hits = (1 – Threads_created / Connections) * 100%

获取所需状态变量值：

sky@localhost : (none) 08:57:16> SHOW /*!50000 GLOBAL*/ STATUS-> LIKE ‘Thread%’;

+——————-+——-+|

Variable_name | Value |

+——————-+——-+

| Threads_created | 3 |

+——————-+——-+

4 rows in set (0.01 sec)

sky@localhost : (none) 09:01:33> SHOW /*!50000 GLOBAL*/ STATUS-> LIKE ‘Connections’;

+—————+——-+|

Variable_name | Value

|+—————+——-+|

Connections | 11 |

+—————+——-+

正常来说，Thread Cache 命中率要在90% 以上才算比较合理。

● 锁定状态：锁定状态包括表锁和行锁两种，我们可以通过系统状态变量获得锁定总次数，锁定造成其他线程等待的次数，以及锁定等待时间信息。

sky@localhost : (none) 09:01:44> SHOW /*!50000 GLOBAL*/ STATUS-> LIKE ‘%lock%’;

+——————————-+——-+|

Variable_name | Value |

+——————————-+——-+

| Innodb_row_lock_current_waits | 0 |

| Innodb_row_lock_time | 0 |

| Innodb_row_lock_time_avg | 0 |

| Innodb_row_lock_time_max | 0 |

| Innodb_row_lock_waits | 0 |

| Table_locks_immediate | 44 |

| Table_locks_waited | 0 |

+——————————-+——-+

通过上述系统变量，我们可以得出表锁总次数，其中造成其他现线程等待的次数。同时还可以得到非常详细的行锁信息，如行锁总次数，行锁总时间，每次行锁等待时间，行锁造成最大等待时间以及当前等待行锁的线程数。通过对这些量的监控，我们可以清晰的了解到系统整体的锁定是否严重。如当Table_locks_waited 与Table_locks_immediate 的比值较大，则说明我们的表锁造成的阻塞比较严重，可能需要调整Query 语句，或者更改存储引擎，亦或者需要调整业务逻辑。当然，具体改善方式必须根据实际场景来判断。而Innodb_row_lock_waits 较大，则说明Innodb 的行锁也比较严重，且影响了其他线程的正常处理。同样需要查找出原因并解决。造成Innodb 行锁严重的原因可能是Query 语句所利用的索引不够合理（Innodb 行锁是基于索引来锁定的），造成间隙锁过大。也可能是系统本身处理能力有限，则需要从其他方面（如硬件设备）来考虑解决。

● Tmp table 状况：Tmp Table 的状况主要是用于监控MySQL 使用临时表的量是否过多，是否有临时表过大而不得不从内存中换出到磁盘文件上。临时表使用状态信息可以通过如下方式获得：

sky@localhost : (none) 09:27:28> SHOW /*!50000 GLOBAL*/ STATUS-> LIKE ‘Created_tmp%’;

+————————-+——-+|

Variable_name | Value |

+————————-+——-+|

Created_tmp_disk_tables | 1 |

| Created_tmp_tables | 46 |

+————————-+——-+

从上面的状态信息可以了解到系统使用了46 次临时表，其中有1 次临时表比较大，无法在内存中完成，而不得不使用到磁盘文件。如果Created_tmp_tables 非常大，则可能是系统中排序操作过多，或者是表连接方式不是很优化。而如果是Created_tmp_disk_tables 与Created_tmp_tables 的比率过高，如超过10%，则我们需要考虑是否tmp_table_size 这个系统参数所设置的足够大。当然，如果系统内存有限，也就没有太多好的解决办法了。

● Binlog Cache 使用状况：Binlog Cache 用于存放还未写入磁盘的Binlog 信息。相关状态变量如下：

sky@localhost : (none) 09:40:38> SHOW /*!50000 GLOBAL*/ STATUS-> LIKE ‘Binlog_cache%’;

+———————–+——-+|

Variable_name | Value |

+———————–+——-+|

Binlog_cache_disk_use | 0 |

| Binlog_cache_use | 0 |

+———————–+——-+

如果Binlog_cache_disk_use 值不为0，则说明Binlog Cache 大小可能不够，建议增加binlog_cache_size 系统参数大小。

● Innodb_log_waits 量：Innodb_log_waits 状态变量直接反应出Innodb LogBuffer 空间不足造成等待的次数。

sky@localhost : (none) 09:43:53> SHOW /*!50000 GLOBAL*/ STATUS-> LIKE ‘Innodb_log_waits’;

+——————+——-+

|Variable_name | Value |

+——————+——-+

| Innodb_log_waits | 0 |

+——————+——-+

该变量值发生的频率将直接影响系统的写入性能，所以当该值达到每秒1 次时就该增加系统参数innodb_log_buffer_size 的值，毕竟这是一个系统共用的缓存，适当增加并不会造成内存不足的问题。

long_query_time = 1
log-slow-queries = /var/youpath/slow.log
log-queries-not-using-indexes

long_query_time 是指执行超过多久的sql会被log下来，这里是1秒。
log-slow-queries 设置把日志写在那里，可以为空，系统会给一个缺省的文件host_name-slow.log，我生成的log就在mysql的data目录
log-queries-not-using-indexes 就是字面意思，log下来没有使用索引的query。

把上述参数打开，运行一段时间，就可以关掉了，省得影响生产环境。

接下来就是分析了，我这里的文件名字叫host-slow.log。
先mysqldumpslow –help以下，俺主要用的是
-s ORDER what to sort by (t, at, l, al, r, ar etc), ‘at’ is default
-t NUM just show the top n queries
-g PATTERN grep: only consider stmts that include this string

-s，是order的顺序，说明写的不够详细，俺用下来，包括看了代码，主要有
c,t,l,r和ac,at,al,ar，分别是按照query次数，时间，lock的时间和返回的记录数来排序，前面加了a的时倒叙
-t，是top n的意思，即为返回前面多少条的数据
-g，后边可以写一个正则匹配模式，大小写不敏感的

mysqldumpslow -s c -t 20 host-slow.log
mysqldumpslow -s r -t 20 host-slow.log

上述命令可以看出访问次数最多的20个sql语句和返回记录集最多的20个sql。
mysqldumpslow -t 10 -s t -g “left join” host-slow.log
这个是按照时间返回前10条里面含有左连接的sql语句。

用了这个工具就可以查询出来那些sql语句是性能的瓶颈，进行优化，比如加索引，该应用的实现方式等。

Pv = concurrent connections * seconds * (web hosts)/ (para connect per a page)/ (time to react)/ (factor)

concurrent connections：并发连接数

Seconds:  pv统计的总时间，单位秒，要计算一天的pv就是86400秒

para connect per a page:         页面衍生连接次数。一个HTML页面可能会请求好几次http连接，如外部的css, js, 图片等。可以估算一下，或者用10。可根据实际情况改变

time to react：http响应时间，可以使用1秒或更少。可根据实际情况改变

factor：因数，一般使用5即可。可根据实际情况计算后推出

web hosts：web服务器数量

* para connect per a page，time to react，factor 这三个参数要根据实际情况分析计算后，确定一个适合的值

推算一下。单台机器1000并发的情况下，一天是1,728,000的pv(1秒响应，10个衍生连接，因子为5的情况下)

# free
total       used       free     shared    buffers     cached
Mem:       4129428    2830048    1299380          0     208524    1838492
-/+ buffers/Cache:     783032    3346396
SWAP:      4192956          0    4192956

解释下各个参数的意思：

Mem：表示物理内存统计
-/+ buffers/cached：表示物理内存的缓存统计。
Swap：表示硬盘上交换分区的使用情况，这里我们不去关心。
系统的总物理内存：4129428（4096MB），但系统当前真正可用的内存并不是第一行free 标记的 2830048，它仅代表未被分配的内存。

单位为MB的查看方法：
# free -m
total       used       free     shared    buffers     cached
Mem:          4032       2764       1268          0        203       1795
-/+ buffers/cache:        765       3267
Swap:         4094          0       4094

我们使用totalA、usedA、freeA、usedB、freeB等名称来代表上面统计数据的各值，A和B分别代表第一行和第二行的数据。
[totalA] 4032：表示物理内存总量。
[usedA] 2764：表示总计分配给缓存（包含buffers 与cache ）使用的数量，但其中可能部分缓存并未实际使用。
[freeA] 1268：未被分配的内存。
[sharedA] 0 ：共享内存，一般系统不会用到，这里也不讨论。
[buffersA] 203：系统分配但未被使用的buffers 数量。
[cachedA] 1795：系统分配但未被使用的cache 数量。buffer 与cache 的区别见后面。

[usedB] 771：实际使用的buffers 与cache 总量，也是实际使用的内存总量。
[freeB] 3261：未被使用的buffers 与cache 和未被分配的内存之和，这就是系统当前实际可用内存。

可以整理出如下等式：
totalA = usedA + free1
totalA = used2 + free2
usedA = buffersA + cachedA + usedB
freeB = buffersA + cachedA + freeA

buffer 与cache 的区别
A buffer is something that has yet to be “written” to disk. A cache is something that has been “read” from the disk and stored for later use.
对于共享内存（Shared memory），主要用于在Unix 环境下不同进程之间共享数据，是进程间通信的一种方法，一般的应用程序不会申请使用共享内存，笔者也没有去验证共享内存对上面等式的影响。

cache 和 buffer的区别：
Cache：高速缓存，是位于CPU与主内存间的一种容量较小但速度很高的存储器。由于CPU的速度远高于主内存，CPU直接从内存中存取数据要等待一定时间周期，Cache中保存着CPU刚用过或循环使用的一部分数据，当CPU再次使用该部分数据时可从Cache中直接调用，这样就减少了CPU的等待时间，提高了系统的效率。Cache又分为一级Cache（L1 Cache）和二级Cache（L2 Cache），L1 Cache集成在CPU内部，L2 Cache早期一般是焊在主板上，现在也都集成在CPU内部，常见的容量有256KB或512KB L2 Cache。

Buffer：缓冲区，一个用于存储速度不同步的设备或优先级不同的设备之间传输数据的区域。通过缓冲区，可以使进程之间的相互等待变少，从而使从速度慢的设备读入数据时，速度快的设备的操作进程不发生间断。

Free中的buffer和cache：（它们都是占用内存）：
buffer : 作为buffer cache的内存，是块设备的读写缓冲区
cache: 作为page cache的内存， 文件系统的cache
如果 cache 的值很大，说明cache住的文件数很多。如果频繁访问到的文件都能被cache住，那么磁盘的读IO必会非常小。

Linux 的这一特性，主要是利用空闲的物理内存，划分出一部份空间，做为 cache 和 buffers ，以此提高数据访问性能。

1、什么是 cache ?

页高速缓存(cache)是 Linux内核实现的一种主要磁盘缓存。它主要用来减少对磁盘的I/O操作。具体地讲，是通过把磁盘中的数据缓存到物理内存中，把对磁盘的访问变为对物理内存的访问。

磁盘高速缓存的价值在于两个方面：第一，访问磁盘的速度要远远低于访问内存的速度，因此，从内存访问数据比从磁盘访问速度更快。第二，数据一旦被访问，就很有可能在短期内再次被访问到。

页高速缓存是由内存中的物理页组成的，缓存中每一页都对应着磁盘中的多个块。每当内核开始执行一个页I/O操作时(通常是对普通文件中页大小的块进行磁盘操作)，首先会检查需要的数据是否在高速缓存中，如果在，那么内核就直接使用高速缓存中的数据，从而避免访问磁盘。

举个例子，当使用文本编辑器打开一个源程序文件时，该文件的数据就被调入内存。编辑该文件的过程中，越来越多的数据会相继被调入内存页。最后，当你编译它的时候，内核可以直接使用页高速缓存中的页，而不需要重新从磁盘读取该文件了。因为用户往往会反复读取或操作同一个文件，所以页高速缓存能减少大量的磁盘操作。

2、cache 如何更新?

由于页高速缓存的缓存作用，写操作实际上会被延迟。当页高速缓存中的数据比后台存储的数据更新时，那么该数据就被称做脏数据。在内存中累积起来的脏页最终必须被写回磁盘。在以下两种情况发生时，脏页被写回磁盘：

◆当空闲内存低于一个特定的阈值时，内核必须将脏页写回磁盘，以便释放内存。

◆当脏页在内存中驻留时间超过一个特定的阈值时，内核必须将超时的脏页写回磁盘，以确保脏页不会无限期地驻留在内存中。

在2.6内核中，由一群内核线程—pdflush后台回写例程统一执行两种工作。

首先，pdflush线程在系统中的空闲内存低于一个特定的阈值时，将脏页刷新回磁盘。该后台回写例程的目的在于在可用物理内存过低时，释放脏页以重新获得内存。特定的内存阈值可以通过dirty_background_ratio sysctl系统调用设置。当空闲内存比阈值：dirty_background_ratio还低时，内核便会调用函数wakeup_bdflush()唤醒一个pdflush线程，随后pdflush线程进一步调用函数background_writeout()开始将脏页写回磁盘。函数background_ writeout()需要一个长整型参数，该参数指定试图写回的页面数目。函数background_writeout()会连续地写出数据，直到满足以下两个条件：

◆已经有指定的最小数目的页被写出到磁盘。

◆空闲内存数已经回升，超过了阈值dirty_background_ratio。

上述条件确保了pdflush操作可以减轻系统中内存不足的压力。回写操作不会在达到这两个条件前停止，除非pdflush写回了所有的脏页，没有剩下的脏页可再被写回了。

为了满足第二个目标，pdflush后台例程会被周期性唤醒(和空闲内存是否过低无关)，将那些在内存中驻留时间过长的脏页写出，确保内存中不会有长期存在的脏页。如果系统发生崩溃，由于内存处于混乱之中，所以那些在内存中还没来得及写回磁盘的脏页就会丢失，所以周期性同步页高速缓存和磁盘非常重要。在系统启动时，内核初始化一个定时器，让它周期地唤醒pdflush线程，随后使其运行函数wb_kupdate()。

如果看到很多的TCP_MEM_HIT ，这表明该文件是从内存缓存读取的，squid已经起作用了！你再用浏览器打开该文件，应该是快如闪电了。。呵呵，大功告成了！还有其他类型的HIT，如TCP_HIT等等，这些是从磁盘读取的，我觉得加速的意义不大，只不过缓解了apache的压力而已。

相应于HTTP请求，下列标签可能出现在access.log文件的第四个域。

TCP_HIT

Squid发现请求资源的貌似新鲜的拷贝，并将其立即发送到客户端。

TCP_MISS

Squid没有请求资源的cache拷贝。

TCP_REFERSH_HIT

Squid发现请求资源的貌似陈旧的拷贝，并发送确认请求到原始服务器。原始服务器返回304（未修改）响应，指示squid的拷贝仍旧是新鲜的。

TCP_REF_FAIL_HIT

Squid发现请求资源的貌似陈旧的拷贝，并发送确认请求到原始服务器。然而，原始服务器响应失败，或者返回的响应Squid不能理解。在此情形下，squid发送现有cache拷贝（很可能是陈旧的）到客户端。

TCP_REFRESH_MISS

Squid发现请求资源的貌似陈旧的拷贝，并发送确认请求到原始服务器。原始服务器响应新的内容，指示这个cache拷贝确实是陈旧的。

TCP_CLIENT_REFRESH_MISS

Squid发现了请求资源的拷贝，但客户端的请求包含了Cache-Control: no-cache指令。Squid转发客户端的请求到原始服务器，强迫cache确认。

TCP_IMS_HIT

客户端发送确认请求，Squid发现更近来的、貌似新鲜的请求资源的拷贝。Squid发送更新的内容到客户端，而不联系原始服务器。

TCP_SWAPFAIL_MISS

Squid发现请求资源的有效拷贝，但从磁盘装载它失败。这时squid发送请求到原始服务器，就如同这是个cache丢失一样。

TCP_NEGATIVE_HIT

在对原始服务器的请求导致HTTP错误时，Squid也会cache这个响应。在短时间内对这些资源的重复请求，导致了否命中。 negative_ttl指令控制这些错误被cache的时间数量。请注意这些错误只在内存cache，不会写往磁盘。下列HTTP状态码可能导致否定 cache（也遵循于其他约束）： 204, 305, 400, 403, 404, 405, 414, 500, 501, 502, 503, 504。

TCP_MEM_HIT

Squid在内存cache里发现请求资源的有效拷贝，并将其立即发送到客户端。注意这点并非精确的呈现了所有从内存服务的响应。例如，某些cache在内存里，但要求确认的响应，会以TCP_REFRESH_HIT, TCP_REFRESH_MISS等形式记录。

TCP_DENIED

因为http_access或http_reply_access规则，客户端的请求被拒绝了。注意被http_access拒绝的请求在第9域的值是NONE/-，然而被http_reply_access拒绝的请求，在相应地方有一个有效值。

TCP_OFFLINE_HIT

当offline_mode激活时，Squid对任何cache响应返回cache命中，而不用考虑它的新鲜程度。

TCP_REDIRECT

重定向程序告诉Squid产生一个HTTP重定向到新的URI（见11.1节）。正常的，Squid不会记录这些重定向。假如要这样做，必须在编译squid前，手工定义LOG_TCP_REDIRECTS预处理指令。

NONE

无分类的结果用于特定错误，例如无效主机名。

相应于ICP查询，下列标签可能出现在access.log文件的第四域。

UDP_HIT

Squid在cache里发现请求资源的貌似新鲜的拷贝。

UDP_MISS

Squid没有在cache里发现请求资源的貌似新鲜的拷贝。假如同一目标通过HTTP请求，就可能是个cache丢失。请对比UDP_MISS_NOFETCH。

UDP_MISS_NOFETCH

跟UDP_MISS类似，不同的是这里也指示了Squid不愿去处理相应的HTTP请求。假如使用了-Y命令行选项，Squid在启动并编译其内存索引时，会返回这个标签而不是UDP_MISS。

UDP_DENIED

因为icp_access规则，ICP查询被拒绝。假如超过95%的到某客户端的ICP响应是UDP_DENIED，并且客户端数据库激活了（见附录A），Squid在1小时内，停止发送任何ICP响应到该客户端。若这点发生，你也可在cache.log里见到一个警告。

UDP_INVALID

Squid接受到无效查询（例如截断的消息、无效协议版本、URI里的空格等）。Squid发送UDP_INVALID响应到客户端。

附:HTTP响应状态码

Table 13-1列出了数字HTTP响应CODE和理由短句。注意Squid和其他HTTP客户端仅仅关注这些数字值。理由短句是纯解释性的，不会影响响应的意 义。对每个状态码，也提供了一个到RFC 2616的具体节的索引。注意状态码0和600是squid使用的非标准的值，不会在RFC里提到。
Table 13-1. HTTP response status codes

mysql> explain SELECT u.*,Y(n.Flocal) lat,X(n.Flocal) lng FROM ylx_user as u JOIN ylx_near_user AS n USING(Fuid)

 WHERE MBRContains(GeomFromText('Polygon((116.415584 40.006519,116.395260 40.033120,116.380138 39.999711,116.404332

 39.981661,116.413262 40.019689,116.386783 40.028007,116.384629 39.987850,116.411660 39.989809,116.406896 40.029465,

116.381084 40.017357,116.415584 40.006519))'),n.Flocal) AND n.Ftype=0\G

*************************** 1. row ***************************

id: 1  select_type: SIMPLE

table: n

type: ALLpossible_keys: Fuid,Flocal

key: NULL

key_len: NULL

ref: NULL

rows: 30

Extra: Using where

*************************** 2. row ***************************

id: 1  select_type: SIMPLE

table: u

type: eq_refpossible_keys: PRIMARY

key: PRIMARY

key_len: 4

ref: youlianxidb.n.Fuid

rows: 1

Extra: 2 rows in set (0.00 sec)

select_type： select 类型

table： 输出结果集的表

type： 表示表的连接类型当表中仅有一行是type的值为system是最佳的连接类型；当select操作中使用索引进行表连接时type的值为ref；

当select的表连接没有使用索引时，经常会看到type的值为ALL，表示对该表进行了全表扫描，这时需要考虑通过创建索引来提高表连接的效率。

possible_keys： 表示查询时,可以使用的索引列.

key： 表示使用的索引

key_len： 索引长度

rows： 扫描范围

Extra： 执行情况的说明和描述

确定问题，并采取相应的优化措施：经过以上步骤，基本可以确认问题出现的原因，可以根据情况采取相应的措施，进行优化提高执行的效率。