Archive for 七月, 2007

\r\n 同时在线访问量继续增大 对于1G内存的服务器明显感觉到吃力严重时甚至每天都会死机 或者时不时的服务器卡一下 这个问题曾经困扰了我半个多月MySQL使用是很具伸缩性的算法,因此你通常能用很少的内存运行或给MySQL更多的被存以得到更好的性能。

安\r\n装好mysql后,配制文件应该在/usr/local/mysql/share/mysql目录中,配制文件有几个,有my-huge.cnf\r\nmy-medium.cnf my-large.cnf\r\nmy-small.cnf,不同的流量的网站和不同配制的服务器环境,当然需要有不同的配制文件了。

一般的情况下,my-\r\nmedium.cnf这个配制文件就能满足我们的大多需要;一般我们会把配置文件拷贝到/etc/my.cnf\r\n只需要修改这个配置文件就可以了,使用mysqladmin variables extended-status –u root –p\r\n可以看到目前的参数,有3个配置参数是最重要的,即key_buffer_size,query_cache_size,table_cache。

key_buffer_size只对MyISAM表起作用,

key_buffer_size\r\n指定索引缓冲区的大小,它决定索引处理的速度,尤其是索引读的速度。一般我们设为16M,实际上稍微大一点的站点 这个数字是远远不够的,通过检查状态值\r\nKey_read_requests和Key_reads,可以知道key_buffer_size设置是否合理。比例key_reads /\r\nkey_read_requests应该尽可能的低,至少是1:100,1:1000更好(上述状态值可以使用SHOW STATUS LIKE\r\n‘key_read%’获得)。 或者如果你装了phpmyadmin\r\n可以通过服务器运行状态看到,笔者推荐用phpmyadmin管理mysql,以下的状态值都是本人通过phpmyadmin获得的实例分析:

这个服务器已经运行了20天
key_buffer_size – 128M
key_read_requests – 650759289
key_reads – 79112
比例接近1:8000 健康状况非常好

另外一个估计key_buffer_size的办法 把你网站数据库的每个表的索引所占空间大小加起来看看以此服务器为例:比较大的几个表索引加起来大概125M 这个数字会随着表变大而变大。

从4.0.1开始,MySQL提供了查询缓冲机制。使用查询缓冲,MySQL将SELECT语句和查询结果存放在缓冲区中,今后对于同样的SELECT语句(区分大小写),将直接从缓冲区中读取结果。根据MySQL用户手册,使用查询缓冲最多可以达到238%的效率。

通过调节以下几个参数可以知道query_cache_size设置得是否合理
Qcache inserts
Qcache hits
Qcache lowmem prunes
Qcache free blocks
Qcache total blocks

Qcache_lowmem_prunes\r\n的值非常大,则表明经常出现缓冲不够的情况,同时Qcache_hits的值非常大,则表明查询缓冲使用非常频繁,此时需要增加缓冲大小\r\nQcache_hits的值不大,则表明你的查询重复率很低,这种情况下使用查询缓冲反而会影响效率,那么可以考虑不用查询缓冲。此外,在SELECT语\r\n句中加入SQL_NO_CACHE可以明确表示不使用查询缓冲。
Qcache_free_blocks,如果该值非常大,则表明缓冲区中碎片很多query_cache_type指定是否使用查询缓冲

我设置:
query_cache_size = 32M
query_cache_type= 1
得到如下状态值:
Qcache queries in cache 12737 表明目前缓存的条数
Qcache inserts 20649006
Qcache hits 79060095  看来重复查询率还挺高的
Qcache lowmem prunes 617913 有这么多次出现缓存过低的情况
Qcache not cached 189896   
Qcache free memory 18573912  目前剩余缓存空间
Qcache free blocks 5328 这个数字似乎有点大 碎片不少
Qcache total blocks 30953
如果内存允许32M应该要往上加点

table_cache\r\n指定表高速缓存的大小。每当MySQL访问一个表时,如果在表缓冲区中还有空间,该表就被打开并放入其中,这样可以更快地访问表内容。通过检查峰值时间的\r\n状态值Open_tables和Opened_tables,可以决定是否需要增加table_cache的值。如果你发现open_tables等于\r\ntable_cache,并且opened_tables在不断增长,那么你就需要增加table_cache的值了(上述状态值可以使用SHOW\r\nSTATUS LIKE\r\n‘Open%tables’获得)。注意,不能盲目地把table_cache设置成很大的值。如果设置得太高,可能会造成文件描述符不足,从而造成性能\r\n不稳定或者连接失败。

对于有1G内存的机器,推荐值是128-256。

笔者设置table_cache = 256
得到以下状态:
Open tables 256
Opened tables 9046
虽\r\n然open_tables已经等于table_cache,但是相对于服务器运行时间来说,已经运行了20天,opened_tables的值也非常低。\r\n因此,增加table_cache的值应该用处不大。如果运行了6个小时就出现上述值 那就要考虑增大table_cache。

如果你不\r\n需要记录2进制log\r\n就把这个功能关掉,注意关掉以后就不能恢复出问题前的数据了,需要您手动备份,二进制日志包含所有更新数据的语句,其目的是在恢复数据库时用它来把数据尽\r\n可能恢复到最后的状态。另外,如果做同步复制( Replication )的话,也需要使用二进制日志传送修改情况。

log_bin指\r\n定日志文件,如果不提供文件名,MySQL将自己产生缺省文件名。MySQL会在文件名后面自动添加数字引,每次启动服务时,都会重新生成一个新的二进制\r\n文件。此外,使用log-bin-index可以指定索引文件;使用binlog-do-db可以指定记录的数据库;使用binlog-ignore-\r\ndb可以指定不记录的数据库。注意的是:binlog-do-db和binlog-ignore-db一次只指定一个数据库,指定多个数据库需要多个语\r\n句。而且,MySQL会将所有的数据库名称改成小写,在指定数据库时必须全部使用小写名字,否则不会起作用。

关掉这个功能只需要在他前面加上#号
#log-bin

开启慢查询日志( slow query log )

慢查询日志对于跟踪有问题的查询非常有用。它记录所有查过long_query_time的查询,如果需要,还可以记录不使用索引的记录。下面是一个慢查询日志的例子:

开启慢查询日志,需要设置参数log_slow_queries、long_query_times、log-queries-not-using-indexes。

log_slow_queries\r\n指定日志文件,如果不提供文件名,MySQL将自己产生缺省文件名。long_query_times指定慢查询的阈值,缺省是10秒。log-\r\nqueries-not-using-indexes是4.1.0以后引入的参数,它指示记录不使用索引的查询。笔者设置long_query_time\r\n=10

笔者设置:
sort_buffer_size = 1M
max_connections=120
wait_timeout =120
back_log=100
read_buffer_size = 1M
thread_cache=32
interactive_timeout=120
thread_concurrency = 4

参数说明:
back_log
要\r\n求MySQL能有的连接数量。当主要MySQL线程在一个很短时间内得到非常多的连接请求,这就起作用,然后主线程花些时间(尽管很短)检查连接并且启动\r\n一个新线程。back_log值指出在MySQL暂时停止回答新请求之前的短时间内多少个请求可以被存在堆栈中。只有如果期望在一个短时间内有很多连接,\r\n你需要增加它,换句话说,这值对到来的TCP/IP连接的侦听队列的大小。你的操作系统在这个队列大小上有它自己的限制。 Unix\r\nlisten(2)系统调用的手册页应该有更多的细节。检查你的OS文档找出这个变量的最大值。试图设定back_log高于你的操作系统的限制将是无效\r\n的。
max_connections
并发连接数目最大,120 超过这个值就会自动恢复,出了问题能自动解决

thread_cache
没找到具体说明,不过设置为32后 20天才创建了400多个线程 而以前一天就创建了上千个线程 所以还是有用的

thread_concurrency
#设置为你的cpu数目x2,例如,只有一个cpu,那么thread_concurrency=2
#有2个cpu,那么thread_concurrency=4

skip-innodb
#去掉innodb支持\r\n \r\n

\r\n \r\n

\r\n

Mysql使用了一个平面事务模型:嵌套的事务是不允许的,在第一个里面使用start \r\ntransaction或者begin之后,第二个事务开始的时候,
自动的提交第一个事务。同样,许多其他的Mysql命令运行的时候都会隐藏的执行一个commit命令,下面是一个列表:
DROP \r\nDATABASE/DROP TABLE
CREATE INDEX/DROP INDEX
ALTER TABLE/RENAME \r\nTABLE
LOCK TABLES/UNLOCK TABLES
SET AUTOCOMMIT=1

\r\n

Mysql4.0.14和4.1.1,支持保存点,可以在事务中关键的地方做标记,需要的话可以部分撤销。

\r\n

Mysql提供了两个变量控制事务行为—AUTOCOMMIT 和 TRANSACTION ISOLATION \r\nLEVEL
默认情况下是自动提交的,SET AUTOCOMMIT=0可以关掉自动提交,如果退出没有提交,则自动回滚。

\r\n

通过SELECT @@AUTOCOMMIT;
取得当前的自动提交模式。
mysql> select \r\n@@AUTOCOMMIT;
+————–+
| @@AUTOCOMMIT |
+————–+
| 1 \r\n|
+————–+
1 row in set (0.00 sec)

\r\n

事务孤立性
Mysql提供了四种孤立级别:
序列化(SERIALIZABLE)
可重复读(REPEATABLE \r\nREAD)
提交的读(READ COMMITTED)
未提交的读(READ UNCOMMITTED)

\r\n

序列化:
提供最大程度的隔离,如果每个事务都以这种孤立级运行就会影响Mysql的性能,因为需要大量的资源来使大量事务在任一时刻不被看到。

\r\n

可重复读:
看起来和序列化的孤立级别很相似。
有一个很重要的不同点:虽然一个事务不能看到其他正在执行的当前事务做出的变化,但是它可以看到新的纪录(其他事务添加到数据库的)。

\r\n

提交的读:
安全性比可重复读要差。
不仅处于这一级的事务可以看到其他事务添加的新纪录,而且其他事务对现存纪录做出的修改一旦被提交,也可以看到。
也就是说,这意味着在事务处理期间,如果其他事务修改了相应的表,那么同一个事务的多个select语句可能返回不同的结果。

\r\n

未提交的读:
提供了事务之间最小程度的隔离。除了容易产生虚幻的读操作和不能重复的读操作外,处于这个孤立级的事务可以读到其他事务还没有提交的
数据。如果这个事务使用其他事务未提交的变化作为计算的基础,然后那些未提交的变化被他们的父事务撤销,则导致了大量的数据变化。

\r\n

可以通过
SET TRANSACTION ISOLATION LEVEL READ COMMITTED;
修改孤立级别。

\r\n

默认是可重复读的

\r\n

取得当前的孤立级别:
mysql> select @@tx_isolation;
+—————–+
| \r\n@@tx_isolation |
+—————–+
| REPEATABLE-READ \r\n|
+—————–+
1 row in set (0.00 sec)

\r\n

默认情况下,这个变量的值是基于每个会话设置的,但是可以通过添加global关键字对所有的会话进行全局设置。
SET GLOBAL \r\nTRANSACTION ISOLATION LEVEL READ COMMITTED;

\r\n

需要super优先权执行这个操作。

\r\n

具有非事物表的伪事务
InnoDB和BDB表支持事物的概念,MyISAM表类型不支持这些锁定机制。所以要明确设置表锁定,以避免同时存在的事物互相侵犯空间。

\r\n

Mysql提供了以下实现表锁定的句法:
LOCK TABLES table-name lock-type,….

\r\n

解锁命令:
UNLOCK TABLES;

\r\n

不用指定解锁的表名。

\r\n

有两种类型的表锁定:读锁定和写锁定。

\r\n

读锁定:
表的读锁定是指设置锁定的线程可以从表中读数据,其他线程也可以。不过每个线程都不能修改锁定的表,只要锁定处于活动状态就不能添加、
更新或者删除纪录。

\r\n

READ锁定的一个变体是READ \r\nLOCAL锁定,它和常规的READ锁定是不同的,因为其他线程可以执行INSERT语句,它和初始化锁定的线程拥有的
会话不冲突。它是为了使用mysqldump工具对一个表同时进行多个INSERT操作而创建的。

\r\n

写锁定:
表的写锁定是指设置锁定的线程可以修改表中的数据,但是其他线程在锁定期间既不能从表中读数据也不能写数据。

\r\n

锁定的优先权:
在同时涉及到WRITE和READ锁定的情况下,MYSQL对于写锁定分配较高的优先级来保证对于表的修改可以尽快地保存到磁盘上。这就降低了
磁盘崩溃或者系统失败导致更新丢失的危险。

\r\n

表锁定重要的缺点之一:
如果一个线程不释放它的锁定,其他试图访问这个已锁定表的尝试都会超时等待,导致了整体性能很大程度的降低。

\r\n \r\n

\r\n

修改视图需要create view 和 delete 权限。

表和视图的命令在同一个命名空间中,所以同一个数据库不能有表名和视图名重复。

可以对其他数据库中的表建视图

视图的定义有以下的限制:
1、from子句中不能有子查询
2、select不能指向系统或者用户的变量
3、select不能指向prepared语法参数
4、定义中的表或视图必须存在
5、不能对临时表建视图,也不能建临时视图
6、视图定义中的表名必须已经存在
7、不能在触发器和视图之间建关联

ORDER BY可以用在视图定义中,但是如果访问视图的select中使用的order by,则视图定义中的ORDER BY被忽略。

语法:
CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]
VIEW view_name [(column_list)]
AS select_statement
[WITH [CASCADED | LOCAL] CHECK OPTION]

ALGORITHM扩展了标准sql,有三个值,默认值是UNDEFINED,预算法则决定了mysql如何处理视图。
对于临时表方式,会将视图的结果放置到临时表中,然后使用临时表执行sql,这样的好处是在临时表建完之后,就会释放在原表上面的锁,这样比MERGE方式更快的释放在访问的表上的锁。
对于UNDEFINED方式,是指有系统自己决定使用临时表方式还是MERGE方式,MERGER方式更高效,且临时表方式不能更新视图的数据。

对于MERGE方式,实际上是把访问视图的SQL拼接到视图本身的sql上面。要求视图的行和表的行之间是一一对应的,如果不存在
这样的一一对应的关系,则会切换到临时表算法。
包含以下关键字的sql,不能使用merge方式:
聚合函数(sum,min,max,count等等)
distinct
group by
having
union或者union all
常量视图

另外,这些视图的纪录也是不能更新和删除的,不能更新和删除纪录的视图除了以上那些情况外,还包括:
select中包含子查询
join
from一个不能更新的视图
from一个表的子查询
算法是临时表的视图

如果视图还想要可以插入纪录,则必须满足以下条件:
视图必须包含基表没有默认值的所有字段
视图列必须是简单的对应表的列,没有在上面进一步的处理。

多于多表视图的可更新性:
首先必须是基于MERGE算法的
表连接必须是内连接
视图中只有一个单表是可以被更新的。

对于多表可更新视图,如果插入其中一个单表是可以的,删除纪录是不允许的

WITH [CASCADED | LOCAL] CHECK OPTION决定了是否允许更新数据使纪录不再满足视图的条件。
这个选项和oracle是类似的
local是只要满足本视图的条件就ok
cascade则是必须满足所有针对该表的所有视图的条件才ok。
如果没有明确是local还是cascade,则默认是cascade。

删除视图:
DROP VIEW [IF EXISTS]
view_name [, view_name] …
[RESTRICT | CASCADE]

显示视图内容:
SHOW CREATE VIEW view_name

从5.0.2开始支持触发器。

\r\n

创建触发器的语法:
CREATE TRIGGER trigger_name trigger_time trigger_event ON \r\ntbl_name FOR EACH ROW trigger_stmt

\r\n

tbl_name:触发器必须建在数据库中的表上,该表必须是永久表,不能在临时表或者视图上面建触发器。
trigger_name:触发器的名字,这个名字在删除触发器的时候可以指定。oracle建触发器的时候不需要指定触发器的名字。
trigger_time:BEFORT \r\nAFTER触发时机。
trigger_event:INSERT,UPDATE,DELETE触发事件。
trigger_stmt:触发器内容。

\r\n

触发器中不能通过表名直接访问本表,需要通过new.col_name和old.col_name访问。
触发器中不能调用存储过程。
触发器中不能使用语法开始或者结束一个进程,例如:START \r\nTRANSACTION,COMMIT,ROLLBACK;
在BEFORE触发器中,AUTO_INCREMENT列的NEW值是0,这个时候还取不到要插入的值呢。

\r\n

创建触发器需要SUPER权限。

\r\n

删除触发器:
DROP TRIGGER tbl_name.trigger_name

\r\n \r\n

\r\n

给apache安装mod_rewrite模块

  如果你的服务器apache还没有安装,那很简单,在编译apache时将mod_rewrite模块编译进去就可以,相关文档可以在www.gbunix.com中找到。如果你的apache已经安装好了,现在只想编译出mod_rewrite.so模块,在apache中进行加载,下面我们就介绍这个方法。

以Solaris操作系统进行举例:

# PATH=/usr/local/bin:/usr/sfw/bin:/usr/ccs/bin: $PATH
# export PATH
# which gcc
# which make

# find ./ -name mod_rewrite.c //在apache的安装目录中寻找mod_rewrite.c文件
# cd PATH/to/mod_rewrite.c //进入包含mod_rewrite.c文件的目录
# apxs -c mod_rewrite.c //apxs请指定绝对路径,在你当前正在使用apache的bin目录里
# apxs -i -a -n mod_rewrite mod_rewrite.la

如果没有什么错误的话,应该在你的apache的modules目录中编译出一个mod_rewrite.so文件。

编辑httpd.conf文件,确认httpd.conf中已经包含mod_rewrite.so的加载语句,如下:

LoadModule rewrite_module modules/mod_rewrite.so

这时,你的apache应该已经支持rewrite了。