MYSQL数据缓存模块求助帖

1、简单的话弄过结构体数组，里面有50个结构体元素，每个结构体包含数据库表中的记录，就是缓存了2、根据题目所说“内存保存最常用的50条数据”，则需要在结构体中增加一项最近访问时间，用于替换算法3、查询时调用自己写的接口，然后根据需要在缓存的结构体数组里查询，查不到就用mysql的接口函数到数据库里面差，修改就是同时修改缓存和数据库，懂查询那个怎么做修改这个也就会了；替换算法可以用LRU；接口函数的定义需要看具体需求，这个没法说4、进行修改 *** 作和多线程进行同步 *** 作时注意必须对缓存加锁，至少要加个写锁5、一般来说，考虑到应用存在多进程 *** 作，可以开个共享内存，缓存放在共享内存中，这个不是题目必须6、关于对缓存的查询，由于只有50条，数量不大，可以直接使用顺序查询7、想到再补充……

1 先调优，确认你的MySQL性能足够好，重新调整架构的代价比较大；2 并不是所有数据都需要缓存，访问频率高，生成代价比较高的才考虑是否缓存，也就是说影响你性能瓶颈的考虑去缓存。
3 修改量大不是问题，好好设计自己访问数据库和缓存的代码。
4完成。

可以通过如下命令查看现在缓存的情况 

[java] view plain copy

mysql> show status like 'qcache%';

+-------------------------+----------+

| Variable_name           | Value    |

+-------------------------+----------+

| Qcache_free_blocks      | 1        |

| Qcache_free_memory      | 10475424 |

| Qcache_hits             | 1        |

| Qcache_inserts          | 1        |

| Qcache_lowmem_prunes    | 0        |

| Qcache_not_cached       | 0        |

| Qcache_queries_in_cache | 1        |

| Qcache_total_blocks     | 4        |

+-------------------------+----------+

8 rows in set (000 sec)

其中各个参数的意义如下： 
Qcache_free_blocks：缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE会对缓存中的碎片进行整理，从而得到一个空闲块。 
Qcache_free_memory：缓存中的空闲内存。 
Qcache_hits：每次查询在缓存中命中时就增大 
Qcache_inserts：每次插入一个查询时就增大。命中次数除以插入次数就是不中比率。 
Qcache_lowmem_prunes：缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个 数字在不断增长，就表示可能碎片非常严重，或者内存很少。(上面的 free_blocks和free_memory可以告诉您属于哪种情况) 
Qcache_not_cached：不适合进行缓存的查询的数量，通常是由于这些查询不是 SELECT 语句或者用了now()之类的函数。 
Qcache_queries_in_cache：当前缓存的查询(和响应)的数量。 
Qcache_total_blocks：缓存中块的数量。 

当在使用中，查询缓存会存储一个 SELECT 查询的文本与被传送到客户端的相应结果。如果之后接收到一个同样的查询，服务器将从查询缓存中检索结果，而不是再次分析和执行这个同样的查询。
注意：查询缓存绝不返回过期数据。当数据被修改后，在查询缓存中的任何相关词条均被转储清除。
在某些表并不经常更改，而你又对它执行大量的相同查询时，查询缓存将是非常有用的。对于许多 WEB 服务器使用大量的动态信息，这是一个很典型的情况。
下面是查询缓存的一个性能数据。（这些结果的产生，是通过在一个 a Linux Alpha 2 x 500 MHz、2GB RAM 和 64MB 查询缓存上执行 MySQL 基准套件和到的）：
如果你执行的所有查询均是简单的（比如从表中一行一行的选取）；但是仍然是不同的，所以该查询不能被缓冲，查询缓存处于活动时，开销为 13%。这可以被看作是最差的情况。然而，在实际情况下，查询是比我们的简单示例要复杂得多的，所以开销通常显着得低。
在只有一行记录表中搜索一行后，搜索将快 238% 。这可以被认为是接近于对一个被缓冲的查询所期望的最小的加速。
如果你希望禁用查询缓存，设置 query_cache_size=0。禁用了查询缓存，将没有明显的开销。（在配置选项 --without-query-cache 的帮助下，查询缓存可以被排除在外码之外）
查询在分析之前先被比较，因而
SELECT FROM tbl_name和Select from tbl_name
对于查询缓存被当作是不同的查询，因而查询需要严格的一致（字节对字节的），才会被认为是同样的。 另外，如果一个客户端使用一个新的连接协议格式或不同于其它客户端的另一个字符集，一个查询将被视为不同的。
使用不同数据库的，使用不同协议版本的，或使用不同的缺省字符串的查询将被认为是不同的查询，并将分别的缓冲。
高速缓冲不对 SELECT CALC_ROWS … 和 SELECT FOUND_ROWS（） … 类型的查询起作用，因为找到的行的数目也是被存储在缓冲里的。
如果查询结果被从查询缓存中返回，那么状态变量 Com_select 将不会被增加，但是 Qcache_hits 却会增加。
查看章节 694 查询缓存的状态和维护。
如果一个表发生的改变 （INSERT, UPDATE, DELETE, TRUNCATE, ALTER 或 DROP TABLE|DATABASE），那么所有这张表使用的缓冲的查询（可能通过一个 MRG_MyISAM 表！）将被得失效，并从缓冲中移除。
InnoDB 表的事务所做的更改将在一个 COMMIT 被完成时，使数据失效。
如果一个查询包括下面的函数，它将不能被缓冲：
函数 函数 函数
User-Defined Functions CONNECTION_ID FOUND_ROWS
GET_LOCK RELEASE_LOCK LOAD_FILE
MASTER_POS_WAIT NOW SYSDATE
CURRENT_TIMESTAMP CURDATE CURRENT_DATE
CURTIME CURRENT_TIME DATABASE
ENCRYPT （只有一个参数调用） LAST_INSERT_ID RAND
UNIX_TIMESTAMP （无参数调用） USER BENCHMARK
如果一个查询包含用户变量，引用 MySQL 系统数据库，或下列之一的格式，SELECT … IN SHARE MODE, SELECT … INTO OUTFILE …， SELECT … INTO DUMPFILE … 或 SELECT FROM AUTOINCREMENT_FIELD IS NULL （检索最后一个插入 ID - ODBC 语句），该查询亦不可以被缓存。
然而，FOUND ROWS（） 将返回正确的值，即使先前的查询是从缓存中读取的。
万一一个查询不使用任何表，或使用临时表，或用户对任何相关表有一个列权限，那么查询将不会被缓存。
在一个查询从查询缓存中读取前，MySQL 将检查用户对所有相关的数据库和表有 SELECT 权限。

---