•query_cache_size/query_cache_type (global)
Query cache 作用于整个 MySQL Instance，主要用来缓存 MySQL 中的 ResultSet，也就是一条SQL语句执行的结果集，所以仅仅只能针对select语句。当我们打开了 Query Cache 功能，MySQL在接受到一条select语句的请求后，如果该语句满足Query Cache的要求(未显式说明不允许使用Query Cache，或者已经显式申明需要使用Query Cache)，MySQL 会直接根据预先设定好的HASH算法将接受到的select语句以字符串方式进行hash，然后到Query Cache 中直接查找是否已经缓存。也就是说，如果已经在缓存中，该select请求就会直接将数据返回，从而省略了后面所有的步骤(如 SQL语句的解析，优化器优化以及向存储引擎请求数据等)，极大的提高性能。
当然，Query Cache 也有一个致命的缺陷，那就是当某个表的数据有任何任何变化，都会导致所有引用了该表的select语句在Query Cache 中的缓存数据失效。所以，当我们的数据变化非常频繁的情况下，使用Query Cache 可能会得不偿失。
Query Cache的使用需要多个参数配合，其中最为关键的是 query_cache_size 和 query_cache_type ，前者设置用于缓存 ResultSet 的内存大小，后者设置在何场景下使用 Query Cache。在以往的经验来看，如果不是用来缓存基本不变的数据的MySQL数据库，query_cache_size 一般 256MB 是一个比较合适的大小。当然，这可以通过计算Query Cache的命中率(Qcache_hits/(Qcache_hits+Qcache_inserts)*100))来进行调整。query_cache_type可以设置为0(OFF)，1(ON)或者2(DEMOND)，分别表示完全不使用query cache，除显式要求不使用query cache(使用sql_no_cache)之外的所有的select都使用query cache，只有显示要求才使用query cache(使用sql_cache)。
•binlog_cache_size (global)
Binlog Cache 用于在打开了二进制日志(binlog)记录功能的环境，是 MySQL 用来提高binlog的记录效率而设计的一个用于短时间内临时缓存binlog数据的内存区域。
一般来说，如果我们的数据库中没有什么大事务，写入也不是特别频繁，2MB～4MB是一个合适的选择。但是如果我们的数据库大事务较多，写入量比较大，可与适当调高binlog_cache_size。同时，我们可以通过binlog_cache_use 以及 binlog_cache_disk_use来分析设置的binlog_cache_size是否足够，是否有大量的binlog_cache由于内存大小不够而使用临时文件(binlog_cache_disk_use)来缓存了。
•key_buffer_size (global)
Key Buffer 可能是大家最为熟悉的一个 MySQL 缓存参数了，尤其是在 MySQL 没有更换默认存储引擎的时候，很多朋友可能会发现，默认的 MySQL 配置文件中设置最大的一个内存参数就是这个参数了。key_buffer_size 参数用来设置用于缓存 MyISAM存储引擎中索引文件的内存区域大小。如果我们有足够的内存，这个缓存区域最好是能够存放下我们所有的 MyISAM 引擎表的所有索引，以尽可能提高性能。
此外，当我们在使用MyISAM 存储的时候有一个及其重要的点需要注意，由于 MyISAM 引擎的特性限制了他仅仅只会缓存索引块到内存中，而不会缓存表数据库块。所以，我们的 SQL 一定要尽可能让过滤条件都在索引中，以便让缓存帮助我们提高查询效率。
•bulk_insert_buffer_size (thread)
和key_buffer_size一样，这个参数同样也仅作用于使用 MyISAM存储引擎，用来缓存批量插入数据的时候临时缓存写入数据。当我们使用如下几种数据写入语句的时候，会使用这个内存区域来缓存批量结构的数据以帮助批量写入数据文件：
insert … select …
insert … values (…) ,(…),(…)…
load data infile… into… (非空表)
•innodb_buffer_pool_size(global)
当我们使用InnoDB存储引擎的时候，innodb_buffer_pool_size 参数可能是影响我们性能的最为关键的一个参数了，他用来设置用于缓存 InnoDB 索引及数据块的内存区域大小，类似于 MyISAM 存储引擎的 key_buffer_size 参数，当然，可能更像是 Oracle 的 db_cache_size。简单来说，当我们 *** 作一个 InnoDB 表的时候，返回的所有数据或者去数据过程中用到的任何一个索引块，都会在这个内存区域中走一遭。
和key_buffer_size 对于 MyISAM 引擎一样，innodb_buffer_pool_size 设置了 InnoDB 存储引擎需求最大的一块内存区域的大小，直接关系到 InnoDB存储引擎的性能，所以如果我们有足够的内存，尽可将该参数设置到足够打，将尽可能多的 InnoDB 的索引及数据都放入到该缓存区域中，直至全部。
我们可以通过 (Innodb_buffer_pool_read_requests – Innodb_buffer_pool_reads) / Innodb_buffer_pool_read_requests * 100% 计算缓存命中率，并根据命中率来调整 innodb_buffer_pool_size 参数大小进行优化。
•innodb_additional_mem_pool_size(global)
这个参数我们平时调整的可能不是太多，很多人都使用了默认值，可能很多人都不是太熟悉这个参数的作用。innodb_additional_mem_pool_size 设置了InnoDB存储引擎用来存放数据字典信息以及一些内部数据结构的内存空间大小，所以当我们一个MySQL Instance中的数据库对象非常多的时候，是需要适当调整该参数的大小以确保所有数据都能存放在内存中提高访问效率的。
这个参数大小是否足够还是比较容易知道的，因为当过小的时候，MySQL 会记录 Warning 信息到数据库的 error log 中，这时候你就知道该调整这个参数大小了。
•innodb_log_buffer_size (global)
这是 InnoDB 存储引擎的事务日志所使用的缓冲区。类似于 Binlog Buffer，InnoDB 在写事务日志的时候，为了提高性能，也是先将信息写入 Innofb Log Buffer 中，当满足 innodb_flush_log_trx_commit 参数所设置的相应条件(或者日志缓冲区写满)之后，才会将日志写到文件(或者同步到磁盘)中。可以通过 innodb_log_buffer_size 参数设置其可以使用的最大内存空间。
注：innodb_flush_log_trx_commit 参数对 InnoDB Log 的写入性能有非常关键的影响。该参数可以设置为0，1，2，解释如下：
0：log buffer中的数据将以每秒一次的频率写入到log file中，且同时会进行文件系统到磁盘的同步 *** 作，但是每个事务的commit并不会触发任何log buffer 到log file的刷新或者文件系统到磁盘的刷新 *** 作
1：在每次事务提交的时候将log buffer 中的数据都会写入到log file，同时也会触发文件系统到磁盘的同步
2：事务提交会触发log buffer 到log file的刷新，但并不会触发磁盘文件系统到磁盘的同步。此外，每秒会有一次文件系统到磁盘同步 *** 作。
此外，MySQL文档中还提到，这几种设置中的每秒同步一次的机制，可能并不会完全确保非常准确的每秒就一定会发生同步，还取决于进程调度的问题。实际上，InnoDB 能否真正满足此参数所设置值代表的意义正常 Recovery 还是受到了不同 OS 下文件系统以及磁盘本身的限制，可能有些时候在并没有真正完成磁盘同步的情况下也会告诉 mysqld 已经完成了磁盘同步。
•innodb_max_dirty_pages_pct (global)
这个参数和上面的各个参数不同，他不是用来设置用于缓存某种数据的内存大小的一个参数，而是用来控制在 InnoDB Buffer Pool 中可以不用写入数据文件中的Dirty Page 的比例(已经被修但还没有从内存中写入到数据文件的脏数据)。这个比例值越大，从内存到磁盘的写入 *** 作就会相对减少，所以能够一定程度下减少写入 *** 作的磁盘IO。
但是，如果这个比例值过大，当数据库 Crash 之后重启的时间可能就会很长，因为会有大量的事务数据需要从日志文件恢复出来写入数据文件中。同时，过大的比例值同时可能也会造成在达到比例设定上限后的 flush *** 作“过猛”而导致性能波动很大。
上面这几个参数是 MySQL 中为了减少磁盘物理IO而设计的主要参数，对 MySQL 的性能起到了至关重要的作用。
thinkphp会对数据库表的字段和你的配置文件还有common,php文件进行缓存,所以每次修改数据库字段或者配置文件,或者common.php文件都需要删除缓存,缓存在runtime文件夹下面,我为了方便,每次都是将整个runtime删除,反正他自己又会重新建立,对了,还有模板标签中的include也要删除缓存才会生效php *** 作mysql步骤：1.$connect=mysql_connect('localhost','root','123456')
or
die('数据库连接失败。'mysql_error())链接mysql。
2.mysql_select_db('database',$connect)选择链接的数据库。
3.mysql_query('Set
names
gb2312')$sql
=
"select
*
from
blog_article"准备要查询的数据。
4.$datas
=
mysql_query($sql)执行sql查询。
5.$data
=
mysql_fetch_assoc($datas)得到查询到的缓存在内存中的一条数据。
6.print_r($data)
相同点：三个函数都是返回数据库中查询到的一行数据（说的再清楚点就是一条数据）。
不同点：mysql_fetch_assoc()用的是数据库中相应的字段名作为的key值（也就是数组下标）
如：filed['id']=1
mysql_fetch_row()用的是自动生成的数字（从0开始依次生成）作为的key值（也就是数组下标）
如：filed[0]=1
mysql_fetch_array()用的是自动生成的数字（从0开始依次生成）作为的key值（也就是数组下标）,而且它还同时生成数据库中相应的字段名作为的key值（也就是数组下标）
如：
filed[0]=1，filed['id']=1也就是说，mysql_fetch_array()将mysql_fetch_assoc()和mysql_fetch_row()查询到的结果合为了一体了。
mysql_fetch_object()与mysql_fetch_assoc()差不多。只是mysql_fetch_assoc()返回的是数组。mysql_fetch_object()返回的是object对象。
mysql_insert_id() 取得上一步
INSERT
*** 作产生的
ID。
mysql_result()
函数返回结果集中一个字段的值。
mysql_num_fields()
函数返回结果集中字段的数目。
mysql_affected_rows()返回前一次
MySQL
*** 作所影响的记录行数。
mysql_num_rows(mysql_query($sql))获得结果集中行的数目。
mysql_pconnect()
函数打开一个到
MySQL
服务器的持久连接。
mysql_pconnect()
和
mysql_connect()
非常相似，但有两个主要区别：
1.
当连接的时候本函数将先尝试寻找一个在同一个主机上用同样的用户名和密码已经打开的（持久）连接，如果找到，则返回此连接标识而不打开新连接。
2.
其次，当脚本执行完毕后到
SQL
服务器的连接不会被关闭，此连接将保持打开以备以后使用（mysql_close()
不会关闭由
mysql_pconnect()
建立的连接）。
mysql_data_seek(mysql_query($sql),8)获得结果集中的第8条数据。（mysql_num_rows(mysql_query($sql))和mysql_data_seek(mysql_query($sql),8)在mysql_unbuffered_query($sql)不可以使用。）
mysql_unbuffered_query($sql)和mysql_query($sql)效果差不多，但是
mysql_unbuffered_query($sql)不缓存。mysql_query($sql)会缓存查询的结果。
mysql_close()关闭mysql的最近的链接。
mysql_field_flags(mysql_query($sql),6)返回第六个字段的表属性输出如：not_null
primary_key
auto_increment
。
mysql_fetch_lengths(mysql_query($sql))返回该条数据的所有字段的每个字段的长度。返回的是一个数字组成的数组。
mysql_field_name(mysql_query($sql),3)返回第三个字段的字段名。
mysql_field_table(mysql_query($sql),0)返回指定字段所在的表名。
mysql_free_result(mysql_query($sql))
函数释放结果内存。
mysql_get_client_info()
函数返回
MySQL
客户端信息。
mysql_get_host_info()
取得
MySQL
主机信息。
欢迎分享，转载请注明来源：内存溢出
微信扫一扫
支付宝扫一扫
评论列表（0条）