监视查询缓存
在启用查询缓存之后,重要的是要理解它是否得到了有效的使用。MySQL 有几个可以查看的变量,可以用来了解缓存中的情况。清单 2 给出了缓存的状态。清单 2. 显示查询缓存的统计信息
+-------------------------+-----------+
| Variable_name | Value |
+-------------------------+-----------+
| Qcache_free_blocks | 37753 |
| Qcache_free_memory | 169738824 |
| Qcache_hits | 3249809 |
| Qcache_inserts | 3730811 |
| Qcache_lowmem_prunes | 0 |
| Qcache_not_cached | 101648 |
| Qcache_queries_in_cache | 62077 |
| Qcache_total_blocks | 162003 |
+-------------------------+-----------+
这些项的解释如表 1 所示。
表 1. MySQL 查询缓存变量
变量名 | 说明 |
Qcache_free_blocks | 缓存中相邻内存块的个数。数目大说明可能有碎片。FLUSH QUERY CACHE 会对缓存中的碎片进行整理,从而得到一个空闲块。 |
Qcache_free_memory | 缓存中的空闲内存。 |
Qcache_hits | 每次查询在缓存中命中时就增大。 |
Qcache_inserts | 每次插入一个查询时就增大。命中次数除以插入次数就是不中比率;用 1 减去这个值就是命中率。在上面这个例子中,大约有 87% 的查询都在缓存中命中。 |
Qcache_lowmem_prunes | 缓存出现内存不足并且必须要进行清理以便为更多查询提供空间的次数。这个数字最好长时间来看;如果这个数字在不断增长,就表示可能碎片非常严重,或者内存很少。(上面的 free_blocks 和 free_memory 可以告诉您属于哪种情况)。 |
Qcache_not_cached | 不适合进行缓存的查询的数量,通常是由于这些查询不是 SELECT 语句。 |
Qcache_queries_in_cache | 当前缓存的查询(和响应)的数量。 |
Qcache_total_blocks | 缓存中块的数量。
none
同一台MySQL服务器启动多个端口wget 二进制的源码包解压 cat INSTLL-BINARY 根据说明操作,具体安装步骤请看 http://mylinux.5d6d.com/thread-7-1-1.html 其中1-4步骤是相同的,第5步,也是最重要的一步,要初始化数据库 因为是多个端口,所以要根据配置文件来初始化多个数据库 比如说有2个端口 则要运行两次 ./scripts/mysql_install_db --datadir=/home/mysql1 --userdir=mysql ./scripts/mysql_install_db --datadir=/home/mysql2 --userdir=mysql 配置文件要编辑成这样 [mysqld0] port = 3300 socket = /tmp/mysql0.sock pid-file = /home/mysql0/localhost.localdomain0.pid datadir = /home/mysql0 #log = /data/mysql0/mysql0.log user = mysql skip-locking skip-name-resolve skip-bdb skip-innodb key_buffer = 128M max_allowed_packet = 1M table_cache = 864 sort_buffer_size = 1M read_buffer_size = 512K read_rnd_buffer_size = 1M myisam_sort_buffer_size = 32M thread_cache_size = 16 query_cache_size = 32M thread_concurrency = 8 #skip-networking wait_timeout=8 max_connections=512 max_connect_errors = 10000000 max_user_connections=20 #slow_queries=/data/mysql0slowquer.sql #log_slow_queries=/data/mysql0slowquer.sql long_query_time=3 log-bin=mysql0-bin ########################### [mysqld1] port = 3301 socket = /tmp/mysql1.sock pid-file = /home/mysql1/localhost.localdomain1.pid datadir = /home/mysql1 #log = /data/mysql1/mysql1.log user = mysql skip-locking skip-name-resolve skip-innodb skip-bdb key_buffer = 128M max_allowed_packet = 1M table_cache = 864 sort_buffer_size = 1M read_buffer_size = 512K read_rnd_buffer_size = 1M myisam_sort_buffer_size = 32M thread_cache_size = 16 query_cache_size = 32M thread_concurrency = 8 #skip-networking wait_timeout=8 max_connections=512 max_connect_errors = 10000000 max_user_connections=20 #log_slow_queries=/data/mysql1slowquer.sql long_query_time=3 log-bin=mysql1-bin ######################################## 把配置文件放在 /etc/my.cnf 最后就该启动了 /usr/local/mysql/bin/mysqld_multi start 0-1 这里的0或1是根据配置文件中"[mysqld0]"来定的。
none
mysql 大量的 unauthenticated user(mysql 加速)近日在数据库方面,发现异常的联机状况该状况在 mysql 下指令Show Processlist; 可以看到问题该问题如下; : 3436942 : unauthenticated user : 192.168.0.52:49607 : : Connect : : login : : 3436943 : unauthenticated user : 192.168.0.52:49608 : : Connect : : login : 会有非常多的 unauthenticated user 尝试做登入使用 mysql 的情况当这情况在无限制的发生时,就会照成系统的停顿在经过多方测试,以及询问官方原厂的响应下发现这属于官方一个系统上的特殊设定,亦可称呼他为 mysql 的 bug 不管连结的的方式是经过 hosts 或是 IP 的模式,他都会对 DNS 做反查mysqld 会尝试去反查 IP -> dns ,由于反查解析 过慢,无法应付快速多量的查询 反查是上层 ISP 所掌控,并不是我们可以解决及要求的在知道问题的症结点后,要解决这个问题就有相对应的方法其方法分为两个步骤, 第一是开启 Mysqld 的时候加入特定的参数启动 第二就是修改 mysql 的联机设定等,如下所示
启动参数; with --skip-name-resolve =>这样就可以关闭反查动作
none
MySQL备份与恢复目前 MySQL 支持的免费备份工具有:mysqldump、mysqlhotcopy,还可以用 SQL 语法进行备份:BACKUP TABLE 或者 SELECT INTO OUTFILE,又或者备份二进制日志(binlog),还可以是直接拷贝数据文件和相关的配置文件。MyISAM 表是保存成文件的形式,因此相对比较容易备份,上面提到的几种方法都可以使用。Innodb 所有的表都保存在同一个数据文件 ibdata1 中(也可能是多个文件,或者是独立的表空间文件),相对来说比较不好备份,免费的方案可以是拷贝数据文件、备份 binlog,或者用 mysqldump。1、mysqldump 1.1 备份 mysqldump 是采用SQL级别的备份机制,它将数据表导成 SQL 脚本文件,在不同的 MySQL 版本之间升级时相对比较合适,这也是最常用的备份方法。 现在来讲一下 mysqldump 的一些主要参数: --compatible=name 它告诉 mysqldump,导出的数据将和哪种数据库或哪个旧版本的 MySQL 服务器相兼容。值可以为 ansi、mysql323、mysql40、postgresql、oracle、mssql、db2、maxdb、no_key_options、no_tables_options、no_field_options 等,要使用几个值,用逗号将它们隔开。当然了,它并不保证能完全兼容,而是尽量兼容。 --complete-insert,-c 导出的数据采用包含字段名的完整 INSERT 方式,也就是把所有的值都写在一行。这么做能提高插入效率,但是可能会受到 max_allowed_packet 参数的影响而导致插入失败。因此,需要谨慎使用该参数,至少我不推荐。 --default-character-set=charset 指定导出数据时采用何种字符集,如果数据表不是采用默认的 latin1 字符集的话,那么导出时必须指定该选项,否则再次导入数据后将产生乱码问题。 --disable-keys 告诉 mysqldump 在 INSERT 语句的开头和结尾增加 /*!40000 ALTER TABLE table DISABLE KEYS */; 和 /*!40000 ALTER TABLE table ENABLE KEYS */; 语句,这能大大提高插入语句的速度,因为它是在插入完所有数据后才重建索引的。该选项只适合 MyISAM 表。 --extended-insert = true|false 默认情况下,mysqldump 开启 --complete-insert 模式,因此不想用它的的话,就使用本选项,设定它的值为 false 即可。 --hex-blob 使用十六进制格式导出二进制字符串字段。如果有二进制数据就必须使用本选项。影响到的字段类型有 BINARY、VARBINARY、BLOB。 --lock-all-tables,-x 在开始导出之前,提交请求锁定所有数据库中的所有表,以保证数据的一致性。这是一个全局读锁,并且自动关闭 --single-transaction 和 --lock-tables 选项。 --lock-tables 它和 --lock-all-tables 类似,不过是锁定当前导出的数据表,而不是一下子锁定全部库下的表。本选项只适用于 MyISAM 表,如果是 Innodb 表可以用 --single-transaction 选项。 --no-create-info,-t 只导出数据,而不添加 CREATE TABLE 语句。 --no-data,-d 不导出任何数据,只导出数据库表结构。 --opt 这只是一个快捷选项,等同于同时添加 --add-drop-tables --add-locking --create-option --disable-keys --extended-insert --lock-tables --quick --set-charset 选项。本选项能让 mysqldump 很快的导出数据,并且导出的数据能很快导回。该选项默认开启,但可以用 --skip-opt 禁用。注意,如果运行 mysqldump 没有指定 --quick 或 --opt 选项,则会将整个结果集放在内存中。如果导出大数据库的话可能会出现问题。 --quick,-q 该选项在导出大表时很有用,它强制 mysqldump 从服务器查询取得记录直接输出而不是取得所有记录后将它们缓存到内存中。 --routines,-R 导出存储过程以及自定义函数。 --single-transaction 该选项在导出数据之前提交一个 BEGIN SQL语句,BEGIN 不会阻塞任何应用程序且能保证导出时数据库的一致性状态。它只适用于事务表,例如 InnoDB 和 BDB。 本选项和 --lock-tables 选项是互斥的,因为 LOCK TABLES 会使任何挂起的事务隐含提交。 要想导出大表的话,应结合使用 --quick 选项。 --triggers 同时导出触发器。该选项默认启用,用 --skip-triggers 禁用它。 其他参数详情请参考手册,我通常使用以下 SQL 来备份 MyISAM 表: /usr/local/mysql/bin/mysqldump -uyejr -pyejr \ --default-character-set=utf8 --opt --extended-insert=false \ --triggers -R --hex-blob -x db_name > db_name.sql 使用以下 SQL 来备份 Innodb 表: /usr/local/mysql/bin/mysqldump -uyejr -pyejr \ --default-character-set=utf8 --opt --extended-insert=false \ --triggers -R --hex-blob --single-transaction db_name > db_name.sql 另外,如果想要实现在线备份,还可以使用 --master-data 参数来实现,如下: /usr/local/mysql/bin/mysqldump -uyejr -pyejr \ --default-character-set=utf8 --opt --master-data=1 \ --single-transaction --flush-logs db_name > db_name.sql 它只是在一开始的瞬间请求锁表,然后就刷新binlog了,而后在导出的文件中加入CHANGE MASTER 语句来指定当前备份的binlog位置,如果要把这个文件恢复到slave里去,就可以采用这种方法来做。 1.2 还原 用 mysqldump 备份出来的文件是一个可以直接倒入的 SQL 脚本,有两种方法可以将数据导入。 直接用 mysql 客户端 例如: /usr/local/mysql/bin/mysql -uyejr -pyejr db_name < db_name.sql 用 SOURCE 语法 其实这不是标准的 SQL 语法,而是 mysql 客户端提供的功能,例如: SOURCE /tmp/db_name.sql; 这里需要指定文件的绝对路径,并且必须是 mysqld 运行用户(例如 nobody)有权限读取的文件。 2、 mysqlhotcopy 2.1 备份 mysqlhotcopy 是一个 PERL 程序,最初由Tim Bunce编写。它使用 LOCK TABLES、FLUSH TABLES 和 cp 或 scp 来快速备份数据库。它是备份数据库或单个表的最快的途径,但它只能运行在数据库文件(包括数据表定义文件、数据文件、索引文件)所在的机器上。mysqlhotcopy 只能用于备份 MyISAM,并且只能运行在 类Unix 和 NetWare 系统上。 mysqlhotcopy 支持一次性拷贝多个数据库,同时还支持正则表达。以下是几个例子: root#/usr/local/mysql/bin/mysqlhotcopy -h=localhost -u=yejr -p=yejr \ db_name /tmp (把数据库目录 db_name 拷贝到 /tmp 下) root#/usr/local/mysql/bin/mysqlhotcopy -h=localhost -u=yejr -p=yejr \ db_name_1 ... db_name_n /tmp root#/usr/local/mysql/bin/mysqlhotcopy -h=localhost -u=yejr -p=yejr \ db_name./regex/ /tmp 更详细的使用方法请查看手册,或者调用下面的命令来查看 mysqlhotcopy 的帮助: perldoc /usr/local/mysql/bin/mysqlhotcopy 注意,想要使用 mysqlhotcopy,必须要有 SELECT、RELOAD(要执行 FLUSH TABLES) 权限,并且还必须要能够有读取 datadir/db_name 目录的权限。 2.2 还原 mysqlhotcopy 备份出来的是整个数据库目录,使用时可以直接拷贝到 mysqld 指定的 datadir (在这里是 /usr/local/mysql/data/)目录下即可,同时要注意权限的问题,如下例: root#cp -rf db_name /usr/local/mysql/data/ root#chown -R nobody:nobody /usr/local/mysql/data/ (将 db_name 目录的属主改成 mysqld 运行用户) 3、 SQL 语法备份 3.1 备份 BACKUP TABLE 语法其实和 mysqlhotcopy 的工作原理差不多,都是锁表,然后拷贝数据文件。它能实现在线备份,但是效果不理想,因此不推荐使用。它只拷贝表结构文件和数据文件,不同时拷贝索引文件,因此恢复时比较慢。 例子: BACK TABLE tbl_name TO '/tmp/db_name/'; 注意,必须要有 FILE 权限才能执行本SQL,并且目录 /tmp/db_name/ 必须能被 mysqld 用户可写,导出的文件不能覆盖已经存在的文件,以避免安全问题。 SELECT INTO OUTFILE 则是把数据导出来成为普通的文本文件,可以自定义字段间隔的方式,方便处理这些数据。 例子: SELECT * INTO OUTFILE '/tmp/db_name/tbl_name.txt' FROM tbl_name; 注意,必须要有 FILE 权限才能执行本SQL,并且文件 /tmp/db_name/tbl_name.txt 必须能被 mysqld 用户可写,导出的文件不能覆盖已经存在的文件,以避免安全问题。 3.2 恢复 用 BACKUP TABLE 方法备份出来的文件,可以运行 RESTORE TABLE 语句来恢复数据表。 例子: RESTORE TABLE FROM '/tmp/db_name/'; 权限要求类似上面所述。 用 SELECT INTO OUTFILE 方法备份出来的文件,可以运行 LOAD DATA INFILE 语句来恢复数据表。 例子: LOAD DATA INFILE '/tmp/db_name/tbl_name.txt' INTO TABLE tbl_name; 权限要求类似上面所述。倒入数据之前,数据表要已经存在才行。如果担心数据会发生重复,可以增加 REPLACE 关键字来替换已有记录或者用 IGNORE 关键字来忽略他们。 4、 启用二进制日志(binlog) 采用 binlog 的方法相对来说更灵活,省心省力,而且还可以支持增量备份。 启用 binlog 时必须要重启 mysqld。首先,关闭 mysqld,打开 my.cnf,加入以下几行: server-id = 1 log-bin = binlog log-bin-index = binlog.index 然后启动 mysqld 就可以了。运行过程中会产生 binlog.000001 以及 binlog.index,前面的文件是 mysqld 记录所有对数据的更新操作,后面的文件则是所有 binlog 的索引,都不能轻易删除。关于 binlog 的信息请查看手册。 需要备份时,可以先执行一下 SQL 语句,让 mysqld 终止对当前 binlog 的写入,就可以把文件直接备份,这样的话就能达到增量备份的目的了: FLUSH LOGS;如果是备份复制系统中的从服务器,还应该备份 master.info 和 relay-log.info 文件。 备份出来的 binlog 文件可以用 MySQL 提供的工具 mysqlbinlog 来查看,如: /usr/local/mysql/bin/mysqlbinlog /tmp/binlog.000001 该工具允许你显示指定的数据库下的所有 SQL 语句,并且还可以限定时间范围,相当的方便,详细的请查看手册。 恢复时,可以采用类似以下语句来做到: /usr/local/mysql/bin/mysqlbinlog /tmp/binlog.000001 | mysql -uyejr -pyejr db_name 把 mysqlbinlog 输出的 SQL 语句直接作为输入来执行它。 如果你有空闲的机器,不妨采用这种方式来备份。由于作为 slave 的机器性能要求相对不是那么高,因此成本低,用低成本就能实现增量备份而且还能分担一部分数据查询压力,何乐而不为呢? 5、 直接备份数据文件 相较前几种方法,备份数据文件最为直接、快速、方便,缺点是基本上不能实现增量备份。为了保证数据的一致性,需要在靠背文件前,执行以下 SQL 语句: FLUSH TABLES WITH READ LOCK;也就是把内存中的数据都刷新到磁盘中,同时锁定数据表,以保证拷贝过程中不会有新的数据写入。这种方法备份出来的数据恢复也很简单,直接拷贝回原来的数据库目录下即可。 注意,对于 Innodb 类型表来说,还需要备份其日志文件,即 ib_logfile* 文件。因为当 Innodb 表损坏时,就可以依靠这些日志文件来恢复。 6、 备份策略 对于中等级别业务量的系统来说,备份策略可以这么定:第一次全量备份,每天一次增量备份,每周再做一次全量备份,如此一直重复。而对于重要的且繁忙的系统来说,则可能需要每天一次全量备份,每小时一次增量备份,甚至更频繁。为了不影响线上业务,实现在线备份,并且能增量备份,最好的办法就是采用主从复制机制(replication),在 slave 机器上做备份。 7、 数据维护和灾难恢复 作为一名DBA(我目前还不是,呵呵),最重要的工作内容之一是保证数据表能安全、稳定、高速使用。因此,需要定期维护你的数据表。以下 SQL 语句就很有用: CHECK TABLE 或 REPAIR TABLE,检查或维护 MyISAM 表 OPTIMIZE TABLE,优化 MyISAM 表 ANALYZE TABLE,分析 MyISAM 表 当然了,上面这些命令起始都可以通过工具 myisamchk 来完成,在这里不作详述。 Innodb 表则可以通过执行以下语句来整理碎片,提高索引速度: ALTER TABLE tbl_name ENGINE = Innodb; 这其实是一个 NULL 操作,表面上看什么也不做,实际上重新整理碎片了。 通常使用的 MyISAM 表可以用上面提到的恢复方法来完成。如果是索引坏了,可以用 myisamchk 工具来重建索引。而对于 Innodb 表来说,就没这么直接了,因为它把所有的表都保存在一个表空间了。不过 Innodb 有一个检查机制叫 模糊检查点,只要保存了日志文件,就能根据日志文件来修复错误。可以在 my.cnf 文件中,增加以下参数,让 mysqld 在启动时自动检查日志文件: innodb_force_recovery = 4 关于该参数的信息请查看手册。 8、 总结 做好数据备份,定只好合适的备份策略,这是一个DBA所做事情的一小部分,万事开头难,就从现在开始吧!
none
myisamchk 修复表今天用mysqlcheck 修复一个大表,竟然用了两个多小时,影响了正常业务,心里那个惭愧呀。后来听同事说修复大表要用myisamchk,以前不知道,学习一下。阶段1:检查你的表 运行myisamchk *.MYI或(myisamchk -e *.MYI,如果你有更多的时间)。使用-s(沉默)选项禁止不必要的信息。 你必须只修复那些myisamchk报告有一个错误的表。对这样的表,继续到阶段2。 如果在检查时,你得到奇怪的错误(例如out of memory错误),或如果myisamchk崩溃,到阶段3。 舞台 2 :简单安全的修复 首先,试试myisamchk -r -q tbl_name(-r -q意味着“快速恢复模式”)。这将试图不接触数据文件来修复索引文件。如果数据文件包含它应有的一切和在数据文件指向正确地点的删除连接,这应该管用并且表可被修复。开始修理下一张表。否则,使用下列过程: 在继续前做数据文件的一个备份。 使用myisamchk -r tbl_name(-r意味着“恢复模式”)。这将从数据文件中删除不正确的记录和已被删除的记录并重建索引文件。 如果前面的步骤失败,使用myisamchk --safe-recover tbl_name。安全恢复模式使用一个老的恢复方法,处理常规恢复模式不行的少数情况(但是更慢)。 如果在修复时,你得到奇怪的错误(例如out of memory错误),或如果myisamchk崩溃,到阶段3。 舞台 3 :困难的修理 如果在索引文件的第一个16K块被破坏,或包含不正确的信息,或如果索引文件丢失,你只应该到这个阶段 。在这种情况下,创建一个新的索引文件是必要的。按如下这样做: 把数据文件移更安全的地方。 使用表描述文件创建新的(空)数据和索引文件: shell> mysql db_name mysql> DELETE FROM tbl_name; mysql> quit 将老的数据文件拷贝到新创建的数据文件之中。(不要只是将老文件移回新文件之中;你要保留一个副本以防某些东西出错。) 回到阶段2。现在myisamchk -r -q应该工作了。(这不应该是一个无限循环)。
none
mysql-5.1.34 源码包下载http://downloads.mysql.com/archives/mysql-5.1/mysql-5.1.34.tar.gz
none
MYSQL慢查询日志分析mysql有一个功能就是可以log下来运行的比较慢的sql语句,默认是没有这个log的,为了开启这个功能,要修改my.cnf或者在mysql启动的时候加入一些参数。如果在my.cnf里面修改,需增加如下几行 long_query_time = 10 log-slow-queries = long_query_time 是指执行超过多久的sql会被log下来,这里是10秒。 log-slow-queries 设置把日志写在那里,为空的时候,系统会给慢查询日志赋予主机名,并被附加slow.log 如果设置了参数log-long-format,那么所有没有使用索引的查询也将被记录。在文件my.cnf或my.ini中加入下面这一行可以记录这些查询 这是一个有用的日志。它对于性能的影响不大(假设所有查询都很快),并且强调了那些最需要注意的查询(丢失了索引或索引没有得到最佳应用) # Time: 070927 8:08:52 # User@Host: root[root] @ [192.168.0.20] # Query_time: 372 Lock_time: 136 Rows_sent: 152 Rows_examined: 263630 select id, name from manager where id in (66,10135); 这是慢查询日志中的一条,用了372秒,锁了136秒,返回152行,一共查了263630行 如果日志内容很多,用眼睛一条一条去看会累死,mysql自带了分析的工具,使用方法如下: 命令行下,进入mysql/bin目录,输入mysqldumpslow –help或--help可以看到这个工具的参数,主要有 Usage: mysqldumpslow [ OPTS... ] [ LOGS... ] Parse and summarize the MySQL slow query log. Options are --verbose verbose --debug debug --help write this text to standard output -v verbose -d debug -s ORDER what to sort by (t, at, l, al, r, ar etc), 'at' is default -r reverse the sort order (largest last instead of first) -t NUM just show the top n queries -a don't abstract all numbers to N and strings to 'S' -n NUM abstract numbers with at least n digits within names -g PATTERN grep: only consider stmts that include this string -h HOSTNAME hostname of db server for *-slow.log filename (can be wildcard), default is '*', i.e. match all -i NAME name of server instance (if using mysql.server startup scrīpt) -l don't subtract lock time from total time -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语句。 一般cpu达到100%都是垃圾SQL和索引不当造成的。 只要硬盘有空余内存不是很小,就可以确定是SQL问题。
none
mount后做软链问题好的,机器1:/data/archivedir /data/stardeals/log/admin机器2:/data1/archivedir 目地:想把机器1的/data/stardeals/log/admin里的log,同步到机器2的/data1/archivedir上 mount没有问题, 但是在机器1上执行ln -s /data/stardeals/log/admin /data/archivedir/adminlog 在机器1上正常 但是登录到机器2上时,adminlog这个link是不可以用的 求助,哈哈
none
MYSQL服务器系统变量查询MYSQL服务器系统变量:C:\Program Files\MySQL\MySQL Server 5.0\bin> mysqld --verbose –help 通过mysqladmin命令来查询MYSQL服务器系统变量: C:\Program Files\MySQL\MySQL Server 5.0\bin>mysqladmin -uroot -p variables > d:\init.txt Enter password: ****** Init.txt部分内容: +---------------------------------+----------------------------------------------------------------+ | Variable_name | Value | +---------------------------------+----------------------------------------------------------------+ | auto_increment_increment | 1 | | auto_increment_offset | 1 | | automatic_sp_privileges | ON | | back_log | 50 ………… | version_compile_machine | ia32 | | version_compile_os | Win32 | | wait_timeout | 28800 | +---------------------------------+----------------------------------------------------------------+ 获得MYSQL实际使用的服务器系统变量: mysql> show variables; 利用like参数来显示具体的服务器系统变量: mysql> show variables like 'init_connect%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | init_connect | | +---------------+-------+ 1 row in set (0.00 sec) 调整MYSQL服务器的系统变量 mysqld服务器维护两种变量。全局变量影响服务器的全局操作。会话变量影响具体客户端连接相关操作。服务器启动时,将所有全局变量初始化为默认值。可以在选项文件或命令行中指定的选项来更改这些默认值。服务器启动后,通过连接服务器并执行SET GLOBAL var_name语句可以更改动态全局变量。要想更改全局变量,必须具有SUPER权限。 方法一: mysql> SHOW VARIABLES LIKE 'query_cache_size'; +------------------+----------+ | Variable_name | Value | +------------------+----------+ | query_cache_size | 23068672 | +------------------+----------+ 1 row in set (0.01 sec) mysql> SET GLOBAL query_cache_size = 31457280; Query OK, 0 rows affected (0.00 sec) mysql> SHOW VARIABLES LIKE 'query_cache_size'; +------------------+----------+ | Variable_name | Value | +------------------+----------+ | query_cache_size | 31457280 | +------------------+----------+ 1 row in set (0.00 sec) 方法二: mysql> show variables like 'query_cache_size%'; +------------------+----------+ | Variable_name | Value | +------------------+----------+ | query_cache_size | 31457280 | +------------------+----------+ 1 row in set (0.00 sec) mysql> SET @@global.query_cache_size = 20971520; Query OK, 0 rows affected (0.09 sec) mysql> show variables like 'query_cache_size%'; +------------------+----------+ | Variable_name | Value | +------------------+----------+ | query_cache_size | 20971520 | +------------------+----------+ 1 row in set (0.00 sec) mysql> select @@query_cache_size; +--------------------+ | @@query_cache_size | +--------------------+ | 20971520 | +--------------------+ 1 row in set (0.06 sec) mysqld服务器还为每个客户端连接维护会话变量。连接时使用相应全局变量的当前值对客户端会话变量进行初始化。客户可以通过SET [SESSION] var_name语句来更改动态会话变量。设置会话变量不需要特殊权限,但客户可以只更改自己的会话变量,而不更改其它客户的会话变量。 mysql> SET sort_buffer_size = 10 * 1024 * 1024; Query OK, 0 rows affected (0.08 sec) mysql> show variables like 'sort_buffer%'; +------------------+----------+ | Variable_name | Value | +------------------+----------+ | sort_buffer_size | 10485760 | +------------------+----------+ 1 row in set (0.00 sec) 注意: 当使用启动选项设置变量时,变量值可以使用后缀K、M或G分别表示千字节、兆字节或gigabytes。例如,下面的命令启动服务器时的键值缓冲区大小为16 megabytes: C:\ProgramFiles\MySQL\MySQL Server 5.0\bin>mysqld--key_buffer_size=16M 后缀的大小写美关系;16M和16m是同样的。 运行时,使用SET语句来设置系统变量。此时,不能使用后缀,但值可以采取下列表达式: mysql> SET sort_buffer_size = 10 * 1024 * 1024; 2 MYSQL服务器状态变量 mysqladmin查看服务器状态变量(动态变化): C:\Program Files\MySQL\MySQL Server 5.0\bin>mysqladmin -uroot -p extended-status Enter password: ****** +-----------------------------------+----------+ | Variable_name | Value | +-----------------------------------+----------+ | Aborted_clients | 0 | | Aborted_connects | 3 | | Binlog_cache_disk_use | 0 | | Binlog_cache_use | 0 | | Bytes_received | 2664 | | Bytes_sent | 96723 | | Com_admin_commands | 0 | | Com_alter_db | 0 | | Com_alter_table | 0 | | Com_analyze | 0 | 该命令和下面命令等效: 获得MYSQL服务器的统计和状态指标: mysql> show status; +-----------------------------------+----------+ | Variable_name | Value | +-----------------------------------+----------+ | Aborted_clients | 0 | | Aborted_connects | 3 | | Binlog_cache_disk_use | 0 | | Binlog_cache_use | 0 | | Bytes_received | 765 | | Bytes_sent | 80349 | | Com_admin_commands | 0 | | Com_alter_db | 0 | | Com_alter_table | 0 | | Com_analyze | 0 | 刷新MYSQL服务器状态变量 mysql> show status like 'Bytes_sent%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Bytes_sent | 53052 | +---------------+-------+ 1 row in set (0.00 sec) mysql> flush status; Query OK, 0 rows affected (0.00 sec) mysql> show status like 'Bytes_sent%'; +---------------+-------+ | Variable_name | Value | +---------------+-------+ | Bytes_sent | 11 | +---------------+-------+ 1 row in set (0.00 sec)
none
mysql 5.0 与 5.1 记录慢查询日志的区别在mysql5.1之前的版本中,只需要log_slow_queries=filename // 注意:这里必须是绝对路径 slow-query-log=1 就可以开启Slow Query log(慢查询日志)了。 但这样在mysql 5.1中并不管用。 日志中会有如下的错误: [Warning] '--log_slow_queries' is deprecated and will be removed in a future release. Please use ''--slow_query_log'/'--slow_query_log_file'' instead. 修改如下: log_output=FILE # also can be FILE,TABLE or TABLE or NONE slow-query-log=1 slow_query_log_file=filename
none
清除mysql庞大的binlog环境:mysql master/slave架构问题:主库硬盘不足 原因:mysql的var下大量bin二进制log,200多个g啊 目标:安全删除binlog 方法:网上搜搜关键词“mysql bin文件 删除”,还真有~~ 相关语句: PURGE {MASTER | BINARY} LOGS TO 'log_name' PURGE {MASTER | BINARY} LOGS BEFORE 'date' 用于删除列于在指定的日志或日期之前的日志索引中的所有二进制日志。这些日志也会从记录在日志索引文件中的清单中被删除,这样被给定的日志成为第一个。 例如: PURGE MASTER LOGS TO 'mysql-bin.010'; PURGE MASTER LOGS BEFORE '2003-04-02 22:46:26'; BEFORE变量的date自变量可以为'YYYY-MM-DD hh:mm:ss'格式。MASTER和BINARY是同义词。 如果您有一个活性的从属服务器,该服务器当前正在读取您正在试图删除的日志之一,则本语句不会起作用,而是会失败,并伴随一个错误。不过,如果从属服务器是休止的,并且您碰巧清理了其想要读取的日志之一,则从属服务器启动后不能复制。当从属服务器正在复制时,本语句可以安全运行。您不需要停止它们。 要清理日志,需按照以下步骤: 1. 在每个从属服务器上,使用SHOW SLAVE STATUS来检查它正在读取哪个日志。 2. 使用SHOW MASTER LOGS获得主服务器上的一系列日志。 3. 在所有的从属服务器中判定最早的日志。这个是目标日志。如果所有的从属服务器是更新的,这是清单上的最后一个日志。 4. 制作您将要删除的所有日志的备份。(这个步骤是自选的,但是建议采用。) 5. 清理所有的日志,但是不包括目标日志 实践: 从库下--- mysql> show slave status\G; …… Master_Log_File: tc-ns-comment-db00-bin.000162 Relay_Master_Log_File: tc-ns-comment-db00-bin.000162 …… 主库下--- mysql> show master log; …………一堆堆 mysql> PURGE MASTER LOGS TO 'tc-ns-comment-db00-bin.000070'; ……等待n长时间 mysql>quit $du -sh ./ 减少了好多g啊,世界清净了~~ 总结:发现这个解决方法,其实就是mysql参考手册的原文cp,但是一个but,问题是不知道原来这个语句是用在这里的啊……汗一下自己
none
mysql中REPAIR TABLE 和 OPTIMIZE TABLE 的用途和区别REPAIR TABLE `table_name` 修复表OPTIMIZE TABLE `table_name` 优化表 REPAIR TABLE 用于修复被破坏的表。 OPTIMIZE TABLE 用于回收闲置的数据库空间, 当表上的数据行被删除时,所占据的磁盘空间并没有立即被回收,使用了OPTIMIZE TABLE命令后这些空间将被回收,并且对磁盘上的数据行进行重排(注意:是磁盘上,而非数据库)。 多数时间并不需要运行OPTIMIZE TABLE,只需在批量删除数据行之后,或定期(每周一次或每月一次)进行一次数据表优化操作即可,只对那些特定的表运行。
none
mysql引擎性能简单测试[硬件配置]CPU : AMD2500+ (1.8G) 内存: 1G/现代 硬盘: 80G/IDE [软件配置] OS : Windows XP SP2 SE : PHP5.2.1 DB : MySQL5.0.37 Web: IIS6 [MySQL表结构] CREATE TABLE `myisam` ( `id` int(11) NOT NULL auto_increment, `name` varchar(100) default NULL, `content` text, PRIMARY KEY (`id`) ) ENGINE=MyISAM DEFAULT CHARSET=gbk; CREATE TABLE `innodb` ( `id` int(11) NOT NULL auto_increment, `name` varchar(100) default NULL, `content` text, PRIMARY KEY (`id`) ) ENGINE=InnoDB DEFAULT CHARSET=gbk; [数据内容] $name = "heiyeluren"; $content = "MySQL支持数个存储引擎作为对不同表的类型的处理器。MySQL存储引擎包括处理事务安全表的引擎和处理非事务安全表的引擎:· MyISAM管理非事务表。它提供高速存储和检索,以及全文搜索能力。MyISAM在所有MySQL配置里被支持,它是默认的存储引擎,除非你配置 MySQL默认使用另 外一个引擎。 ·MEMORY存储引擎提供“内存中”表。MERGE存储引擎允许集合将被处理同样的MyISAM表作为一个单独的表。就像MyISAM一样,MEMORY和MERGE存储引擎处理非事务表,这两个引擎也都被默认包含在MySQL中。释:MEMORY存储引擎正式地被确定为HEAP引擎。· InnoDB和BDB存储引擎提供事务安全表。BDB被包含在为支持它的操作系统发布的MySQL-Max二进制分发版里。InnoDB也默认被包括在所有MySQL 5.1二进制分发版里,你可以按照喜好通过配置MySQL来允许或禁止任一引擎。·EXAMPLE存储引擎是一个“存根”引擎,它不做什么。你可以用这个引擎创建表,但没有数据被存储于其中或从其中检索。这个引擎的目的是服务,在MySQL源代码中的一个例子,它演示说明如何开始编写新存储引擎。同样,它的主要兴趣是对开发者。"; [插入数据-1] (innodb_flush_log_at_trx_commit=1) MyISAM 1W:3/s InnoDB 1W:219/s MyISAM 10W:29/s InnoDB 10W:2092/s MyISAM 100W:287/s InnoDB 100W:没敢测试 [插入数据-2] (innodb_flush_log_at_trx_commit=0) MyISAM 1W:3/s InnoDB 1W:3/s MyISAM 10W:30/s InnoDB 10W:29/s MyISAM 100W:273/s InnoDB 100W:423/s [插入数据3] (innodb_buffer_pool_size=1024M) InnoDB 1W:3/s InnoDB 10W:33/s InnoDB 100W:607/s [插入数据4] (innodb_buffer_pool_size=256M, innodb_flush_log_at_trx_commit=1, set autocommit=0) InnoDB 1W:3/s InnoDB 10W:26/s InnoDB 100W:379/s [MySQL 配置文件] (缺省配置) # MySQL Server Instance Configuration File [client] port=3306 default-character-set=gbk [mysqld] port=3306 basedir="C:/mysql50/" datadir="C:/mysql50/Data/" default-character-set=gbk default-storage-engine=INNODB sql-mode="STRICT_TRANS_TABLES,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION" max_connections=100 query_cache_size=0 table_cache=256 tmp_table_size=50M thread_cache_size=8 myisam_max_sort_file_size=100G myisam_max_extra_sort_file_size=100G myisam_sort_buffer_size=100M key_buffer_size=82M read_buffer_size=64K read_rnd_buffer_size=256K sort_buffer_size=256K innodb_additional_mem_pool_size=4M innodb_flush_log_at_trx_commit=1 innodb_log_buffer_size=2M innodb_buffer_pool_size=159M innodb_log_file_size=80M innodb_thread_concurrency=8 【总结】 可以看出 在MySQL 5.0里面,MyISAM和InnoDB存储引擎性能差别并不是很大,针对InnoDB来说,影响性能的主要是 innodb_flush_log_at_trx_commit 这个选项,如果设置为1的话,那么每次插入数据的时候都会自动提交,导致性能急剧下降,应该是跟刷新日志有关系,设置为0效率能够看到明显提升,当然,同样你可以SQL中提交“SET AUTOCOMMIT = 0”来设置达到好的性能。另外,还听说通过设置innodb_buffer_pool_size能够提升InnoDB的性能,但是我测试发现没有特别明显的提升。 基本上我们可以考虑使用InnoDB来替代我们的MyISAM引擎了,因为InnoDB自身很多良好的特点,比如事务支持、存储过程、视图、行级锁定等等,在并发很多的情况下,相信InnoDB的表现肯定要比MyISAM强很多,当然,相应的在my.cnf中的配置也是比较关键的,良好的配置,能够有效的加速你的应用。 如果不是很复杂的Web应用,非关键应用,还是可以继续考虑MyISAM的,这个具体情况可以自己斟酌。
none
MySQL replication 详细配置1. 设置master(1) 修改配置文件 # vim /etc/my.cf 在[mysqld]部分添加 server-id=1 log-bin=mysql-bin 改完后重启mysqld服务 # service mysqld restart (2) 设置mysql数据库的root访问密码 # mysqladmin -u root password '123' # mysql -u root -p 输入密码‘123’登陆mysql mysql> grant replication slave on *.* to 'test'@'10.0.2.61' identified by '123'; 说明:这里的test是为slave端设置的访问master端mysql数据的用户,密码为123,这里的10.0.2.61为slave的ip。 mysql> flush tables with read lock; 锁定数据库,此时不允许更改任何数据 mysql> show master status; 查看状态,这些数据是要记录的,一会要在slave端用到 +------------------+----------+--------------+------------------+ | File | Position | Binlog_Do_DB | Binlog_Ignore_DB | +------------------+----------+--------------+------------------+ | mysql-bin.000022 | 229 | | | +------------------+----------+--------------+------------------+ 2. 设置slave # vim /etc/my.cnf 在[mysqld]部分加入 server-id=2 //设置数据库id,可以随便设置,但是不能和Master重复。 # scp -r 10.0.2.62:/var/lib/mysql/库名/* /var/lib/mysql/库名 这里的/var/lib/mysql 是数据库的datadir,不要搞混了。从master把所有数据库文件拷贝到slave,目的是数据的一致,mysql库就不用拷贝了,因为slave上也有一些配置保存在mysql库里。 # service mysqld restart # mysql -u root -p mysql> slave stop; 停止slave服务 mysql> change master to ->master_host=‘10.0.2.61’, //主服务器的IP地址 ->master_user='test', //同步数据库的用户 ->master_password='123', //同步数据库的密码 ->master_log_file='mysql-bin.000022', //主服务器二进制日志的文件名(前面要求记住的参数) -> master_log_pos=229; //日志文件的开始位置(前面要求记住的参数) 注:有时需要指定主mysql的端口号,参数为 master_port=3306 mysql> unlock tables; master上打开锁定的数据库 mysql> slave start; 启动同步数据库的线程 mysql> show slave status\G;查看状态 确认以下两项参数都为yes Slave_IO_Running: Yes Slave_SQL_Running: Yes
none
减少MySQL的Sleep进程有效方法经常遇到很多朋友问到,他的MySQL中有很多Sleep进程,严重占用MySQL的资源,现在分析一下出现这种现象的原因和解决办法:1,通常来说,MySQL出现大量Sleep进程是因为采用的PHP的MySQL长链接数据库方式,即使用了mysql_pconnect来打开链接数据库,解决办法就是使用“短”链接,即mysql_connect函数。 2,在使用mysql_connect短链接方式打开数据库,每个页面在打开数据库后,执行SQL完成,当页面脚本结束的时候,这个MySQL连接会自动关闭并且释放内存。但仍然出现大量Sleep进程,可以看看网站是否存在以下几个方面的问题。 A,硬盘上存在大量的静态文件,或者WEB服务器负荷太重,在处理HTTP请求响应变得太慢,这样也有可能导致出现大量Sleep进程,解决方法适当调整WEB服务参数和文件,一味的静态或者缓存化网页内容并不是灵丹妙药。 B,在网页脚本中,有些计算和应用可能非常耗时,比如在0秒的时候打开数据库执行完一段SQL代码后,网页脚本随即花了20秒钟进行一段复杂的运算,或者是require了一个庞大的PHP文件(比如含有几千个违规关键字的过滤函数),哪么这个时候在MySQL后台看到的进程中,这个20秒的过程MySQL并没有做任何事情了,一直处于Sleep状态,直到这个页面执行完毕或者达到wait_timeout值(被强行关闭),优化网页脚本,尽量让程序快速运行,或者在执行这段耗时的运行过程中,执行mysql_close把当前MySQL链接强行关闭。 C,在采集站中,MySQL中大量的Sleep进程这类现象尤其明显(比如很多网友问道DeDeCMS的MySQL中出现大量Sleep),因为大部的采集器页面在运行过程中,事先打开了一个MySQL链接(可能是为了验证用户权限等),然后开始使用file_get_contents之类的操作去获取一个远程的网页内容,如果这个远程的站点访问速度太慢,比如花了10秒时间才把网页取回,哪么当前采集脚本程序就一直阻塞在这里,并且MySQL啥事也没干,一直处于Sleep状态。解决方法同上,在发出file_get_contents采集远程网页的时候,使用mysql_close强行关闭MySQL的连接,等采集完成在适当需要的时候再重新mysql_connect即可。 总的说来,MySQL是一个非常高效快速的数据库,要让他发挥到最大的性能,同时也不要过量的去掘取他的优势所在,适当的分表(超过10G的表,在打开和关闭以前更新的时候效率明显下降很多),尽可能的优化SQL都可以做到事半功倍的。
none
|