Submitted by yejr on 周一, 2007/10/15 - 20:43
硬件: Intel(R) Xeon(R) CPU 5130 @ 2.00GHz * 2, 4G RAM, 564G SAS
软件: Red Hat Enterprise Linux AS release 4 (Nahant Update 4) 2.6.9 42.ELsmp (32-bit), MySQL 5.0.27-standard-log
总记录数: 1016126, 每行平均大小 46822
1. 导出测试
1.1 导出成文本
方法: SELECT * INTO OUTFILE '/backup/yejr.txt' FROM yejr;
耗时: 3252.15 秒
1.2 导出成 .sql 文件
方法: mysqldump -t -n --default-character-set=latin1 test yejr > /backup/yejr.sql
耗时: 2124 sec
结论: 用 mysqludmp 导出数据是相对较快的方法.
2. 导入测试
2.1 导入 txt 文件
方法: mysql test < /backup/yejr.txt
耗时: 3317.62 sec
Submitted by yejr on 周日, 2007/09/16 - 16:45
前言:设置启动选项 innodb_file_per_table 即可启用独立表空间。不过,InnoDB总是需要共享标空间,.ibd文件对InnoDB不足以去运行,共享表空间包含熟悉的ibdata文件,InnoDB把内部数据词典和撤销日志(undo log)放在这个文件中。
测试环境:Windows XP, MySQL 6.0.0-alpha-community-nt-debug
1. 在不设定 innodb_file_per_table 的情况下(即使用共享表空间),创建一个表。
2. 关闭MySQL
3. 启用 innodb_file_per_table
4. 执行 OPTIMIZE TABLE 或者 ALTER TABLE 等空(NULL)操作
反之也一样
Submitted by yejr on 周日, 2007/09/16 - 15:32
前言:设置启动选项 innodb_file_per_table 即可启用独立表空间。不过,InnoDB总是需要共享标空间,.ibd文件对InnoDB不足以去运行,共享表空间包含熟悉的ibdata文件,InnoDB把内部数据词典和未作日志放在这个文件中。
测试环境:Windows XP, MySQL 6.0.0-alpha-community-nt-debug
先来查看一下该表的状态:
mysql> SHOW TABLE STATUS LIKE 'yejr'\G
*************************** 1. row ***************************
Name: yejr
Engine: InnoDB
Version: 10
Row_format: Compact
Rows: 162049
Avg_row_length: 80
Data_length: 13123584
Max_data_length: 0
Submitted by yejr on 周日, 2007/08/19 - 17:09
看看正序取得结果的耗时:
mysql>SELECT a.HandicapID, FROM_UNIXTIME( a.AddTime, '%y-%c-%e %H:%i' ) AS ShowAddTime, a.MatchID, a.MakerID, a.HandicapNumber ...
FROM MatchHandicap AS a
LEFT JOIN MatchInfo AS b ON ( a.MatchID = e.MatchID )
LEFT JOIN Team AS c ON ( e.HomeID = c.TeamID )
LEFT JOIN Team AS d ON ( e.AwayID = d.TeamID )
LEFT JOIN BookMaker AS e ON ( a.MakerID = e.MakerID ) ORDER BY a.HandicapID LIMIT 11910298, 20;
........
........
20 rows in set (1330 sec)
很恐怖吧,暂且不论这个SQL语句其他可以再优化的地方,把它改造成用倒序取得结果的方式试试看:
Submitted by yejr on 周四, 2007/08/16 - 20:51
有一个表 tbl1 的结构如下:
CREATE TABLE `tbl1` (
`id` int(10) unsigned NOT NULL auto_increment,
`name` char(20) NOT NULL default '',
PRIMARY KEY (`id`),
KEY `name` (`name`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8;
该表里已经存在了200万条记录.
现在, 需要把 tbl1 中的所有记录全部导到另一个完全相同的表 tbl2 中去.
1. 如果采用以下传统的方式, 则执行时间为: 98.01s
mysql>INSERT INTO tbl2 SELECT * FROM tbl1;
Query OK, 2000000 row affected (1 min 38.01 sec)
Records: 2000000 Duplicates: 0 Warnings: 0
Submitted by yejr on 周二, 2007/08/14 - 21:39
1、先来看看多次删除插入操作后的表索引情况
mysql> SHOW INDEX FROM `tbl_name`;
+----------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+----------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| tbl_name | 0 | PRIMARY | 1 | StepID | A | 1 | NULL | NULL | | BTREE | |
Submitted by yejr on 周日, 2007/07/15 - 15:56
原文来自:http://hackmysql.com/mysqlreportdoc
mysqlreport 文档
mysqlreport 以很友好的方式显示
MySQL状态变。事实上,它几乎报告了所有的状态。不像 SHOW STATUS 只是在显示了100多个状态值,mysqlreport 则以人性化的方式阐释和格式化了这些状态值,大大增加了其可读性。可以
点击这里 查看mysqlreport的例子。
mysqlreport 的好处是可以快速的查看各种状态参数组,从而了解服务器的运行状态情况,而无需从 SHOW STATUS 的结果中人工计算。例如索引读取比率是个重要的参数,但是 SHOW STATUS 中并没有显示;它是一个推断值(key_reads 和 key_read_requests 的比值)。
Submitted by yejr on 周三, 2007/06/27 - 09:09
一、概述
事件调度器是在 MySQL 5.1 中新增的另一个特色功能,可以作为定时任务调度器,取代部分原先只能用操作系统任务调度器才能完成的定时功>能。例如,Linux 中的 crontabe 只能精确到每分钟执行一次,而 MySQL 的事件调度器则可以实现每秒钟执行一个任务,这在一些对实时性要>求较高的环境下就非常实用了。
事件调度器是定时触发执行的,在这个角度上也可以称作是
"临时的触发器"。触发器只是针对某个表产生的事件执行一些语句,而事件调度器则是在某一个(间隔)时间执行一些语句。事件是由一个特定的
线程来管理的,也就是所谓的
Submitted by yejr on 周二, 2007/06/26 - 10:50
一、概述
相信有很多人经常会问同样的一个问题:当 MySQL
的总记录数超过了100万后,会出现性能的大幅度下降吗?答案是肯定的,但是性能下降>的比率不一而同,要看系统的架构、应用程序、还有>包括索引、服务器硬件等多种因素而定。当有网友问我这个问题的时候,我最常见的回答>就是:分表,可以根据id区间或者时间先后顺序等多
种规则来分表。分表很容易,然而由此所带来的应用程序甚至是架构方面的改动工作却不>容小觑,还包括将来的扩展性等。
在以前,一种解决方案就是使用 MERGE
Submitted by yejr on 周四, 2007/06/21 - 10:22
MySQL 5.1 中,在复制方面的改进就是引进了新的复制技术:基于行的复制。简言之,这种新技术就是关注表中发生变化的记录,而非以前
的照抄 binlog 模式。从 MySQL 5.1.12 开始,可以用以下三种模式来实现:基于SQL语句的复制(statement-based replication, SBR),基于行的复制(row-based replication, RBR),混合模式复制(mixed-based replication, MBR)。相应地,binlog的格式也有三种:STATEMENT,ROW,MIXED。MBR 模式中,SBR 模式是默认的。
在运行时可以动态低改变binlog的格式,除了以下几种情况:
页面
最近评论