膘叔

好文推荐：五款常用mysql slow log分析工具的比较

gouki — 2010-06-10 09:11

一直在用MYSQL，因此对于慢查询就非常在意，虽然自己写代码的时候不是特别注意，但真正上线后还是要关注关注的。

最简单的看LOG就是用phpmyadmin查看一下，但这终究不是办法。所幸，工具还是很多的。javaeye上就有人贴出了工具和使用方法：

启用 slow log

有两种启用方式:

1, 在my.cnf 里通过 log-slow-queries[=file_name]

2, 在mysqld进程启动时,指定--log-slow-queries[=file_name]选项

比较的五款常用工具

mysqldumpslow, mysqlsla, myprofi, mysql-explain-slow-log, mysqllogfilter

mysqldumpslow, mysql官方提供的慢查询日志分析工具. 输出图表如下:

主要功能是, 统计不同慢sql的

出现次数(Count),

执行最长时间(Time),

累计总耗费时间(Time),

等待锁的时间(Lock),

发送给客户端的行总数(Rows),

扫描的行总数(Rows),

用户以及sql语句本身(抽象了一下格式, 比如 limit 1, 20 用 limit N,N 表示).

mysqlsla, hackmysql.com推出的一款日志分析工具(该网站还维护了 mysqlreport, mysqlidxchk 等比较实用的mysql工具)

整体来说, 功能非常强大. 数据报表,非常有利于分析慢查询的原因, 包括执行频率, 数据量, 查询消耗等.

格式说明如下:

总查询次数 (queries total), 去重后的sql数量 (unique)

输出报表的内容排序(sorted by)

最重大的慢sql统计信息, 包括平均执行时间, 等待锁时间, 结果行的总数, 扫描的行总数.

Count, sql的执行次数及占总的slow log数量的百分比.

Time, 执行时间, 包括总时间, 平均时间, 最小, 最大时间, 时间占到总慢sql时间的百分比.

95% of Time, 去除最快和最慢的sql, 覆盖率占95%的sql的执行时间.

Lock Time, 等待锁的时间.

95% of Lock , 95%的慢sql等待锁时间.

Rows sent, 结果行统计数量, 包括平均, 最小, 最大数量.
Rows examined, 扫描的行数量.

Database, 属于哪个数据库

Users, 哪个用户,IP, 占到所有用户执行的sql百分比

Query abstract, 抽象后的sql语句

Query sample, sql语句

除了以上的输出, 官方还提供了很多定制化参数, 是一款不可多得的好工具.

mysql-explain-slow-log, 德国人写的一个perl脚本.
http://www.willamowius.de/mysql-tools.html

功能上有点瑕疵, 不仅把所有的 slow log 打印到屏幕上, 而且统计也只有数量而已. 不推荐使用.

mysql-log-filter, google code上找到的一个分析工具.提供了 python 和 php 两种可执行的脚本.
http://code.google.com/p/mysql-log-filter/

功能上比官方的mysqldumpslow, 多了查询时间的统计信息(平均,最大, 累计), 其他功能都与 mysqldumpslow类似.
特色功能除了统计信息外, 还针对输出内容做了排版和格式化, 保证整体输出的简洁. 喜欢简洁报表的朋友, 推荐使用一下.

myprofi, 纯php写的一个开源分析工具.项目在 sourceforge 上.
http://myprofi.sourceforge.net/

功能上, 列出了总的慢查询次数和类型, 去重后的sql语句, 执行次数及其占总的slow log数量的百分比.
从整体输出样式来看, 比mysql-log-filter还要简洁. 省去了很多不必要的内容. 对于只想看sql语句及执行次数的用户来说, 比较推荐.

总结

工具/功能	一般统计信息	高级统计信息	脚本	优势
mysqldumpslow	支持	不支持	perl	mysql官方自带
mysqlsla	支持	支持	perl	功能强大,数据报表齐全,定制化能力强.
mysql-explain-slow-log	支持	不支持	perl	无
mysql-log-filter	支持	部分支持	python or php	不失功能的前提下,保持输出简洁
myprofi	支持	不支持	php	非常精简

---EOF---
作者：galaxystar，来自：http://www.javaeye.com/topic/242516，他现在的博客是：http://kenwublog.com/。

mysql server 小技巧

gouki — 2010-05-25 07:03

很多人都使用过mysql命令行，不可否认的是在命令行下如果频繁切换use的database，你会感觉到很迷惘，不太清楚当前的库或表是哪个，于是发现这个技巧后就欣欣然的COPY下来与各位一起分享一下。

在my.cnf 的 mysql 端添加如下设置

[mysql]
#no-auto-rehash # faster start of mysql but no tab completition
prompt="(\u:mysql1@linuxbyte.org \R:\m)[\d]: "

会产生如下效果:

root@ubuntu:/home/hew# mysql -u hew -p
Enter password: 
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 320
Server version: 5.1.41-3ubuntu12.1 (Ubuntu)
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
 
(hew:mysql1@linuxbyte.org 21:12)[(none)]: use linuxbyte  #注意这里
 
Database changed
 
(hew:mysql1@linuxbyte.org 21:13)[linuxbyte]: use linuxsky; #这里
 
Reading table information for completion of table and column names
You can turn off this feature to get a quicker startup with -A
Database changed
 
(hew:mysql1@linuxbyte.org 21:13)[linuxsky]: #这里

如上所示我们可以在mysql命令行下显示当前的mysql 用户，所在主机，时间和所用的数据库。
这个在关键时刻可以让我们避免很多误操作。

原文来自：http://www.blogread.cn/it/article.php?id=1605

MySQL时区设置

gouki — 2010-05-23 20:57

MySQL 时区默认是服务器的时区。
可以通过以下命令查看

SQL代码

mysql> SHOW VARIABLES LIKE '%time_zone%';
+------------------+--------+
| Variable_name | Value |
+------------------+--------+
| system_time_zone | CST |
| time_zone | SYSTEM |
+------------------+--------+
2 rows IN SET (0.00 sec)

可以通过修改my.cnf, 在 [mysqld] 之下加来修改时区。

SQL代码

default-time-zone=timezone
例如：
default-time-zone='+8:00'

改了记得重启msyql.
注意一定要在 [mysqld] 之下加，否则会出现错误: unknown variable ‘default-time-zone=+8:00′

另外也可以通过命令

SQL代码

SET time_zone=timezone
例如：比如北京时间（GMT+0800）
SET time_zone='+8:00'

这个和php的时区设置又有点差别，比如北京时间在php中是

PHP代码

date_default_timezone_set('Etc/GMT-8');

美国pst时间（GMT-08:00）

SQL代码

SET time_zone = '-8:00';

SQL代码

mysql> SET time_zone = '+8:00';
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT now();
+---------------------+
| now() |
+---------------------+
| 2008-12-29 11:26:36 |
+---------------------+
1 row IN SET (0.00 sec)
mysql> SET time_zone = '-8:00';
Query OK, 0 rows affected (0.00 sec)
mysql> SELECT now();
+---------------------+
| now() |
+---------------------+
| 2008-12-28 19:27:09 |
+---------------------+
1 row IN SET (0.00 sec)

原文来自，冰山上的播客，http://xinsync.xju.edu.cn/index.php/archives/6842，略作修改。

MySQL索引的知识点

gouki — 2010-05-19 13:21

数据库是否建索引以及如何更好的建索引，当然是有讲究的。虽然都知道建了索引后，在按条件搜索的时候速度会快很多，但其实，如果索引建的不合理，反而是使得数据库效率降低。何时需要建索引，其实是值得深究的，创建之后，怎样判断效率，当然还得好好学习。要多做尝试才会知道。

这一篇讲的比较详细，所以就转载了，来自冰山的http://xinsync.xju.edu.cn/index.php/archives/6845。

在数据库表中，对字段建立索引可以大大提高查询速度。假如我们创建了一个 mytable表：

SQL代码

CREATE TABLE mytable(
ID INT NOT NULL,
username VARCHAR(16) NOT NULL
);

我们随机向里面插入了10000条记录，其中有一条：5555, admin。

在查找 username=”admin” 的记录 SELECT * FROM mytable WHERE username=’admin’; 时，如果在username上已经建立了索引，MySQL无须任何扫描，即准确可找到该记录。相反，MySQL会扫描所有记录，即要查询10000条记录。

索引分单列索引和组合索引。单列索引，即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。组合索引，即一个索包含多个列。

索引的类型包括：

（1）普通索引
这是最基本的索引，它没有任何限制。它有以下几种创建方式：
● 创建索引

SQL代码

CREATE INDEX indexName ON mytable(username(length));

如果是CHAR，VARCHAR类型，length可以小于字段实际长度；如果是BLOB和TEXT类型，必须指定 length，下同。
● 修改表结构

SQL代码

ALTER mytable ADD INDEX [indexName] ON (username(length))

● 创建表的时候直接指定

SQL代码

CREATE TABLE mytable(
ID INT NOT NULL,
username VARCHAR(16) NOT NULL,
INDEX [indexName] (username(length))
);

删除索引的语法：

SQL代码

DROP INDEX [indexName] ON mytable;

（2）唯一索引

它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：
● 创建索引

SQL代码

CREATE UNIQUE INDEX indexName ON mytable(username(length))

● 修改表结构

SQL代码

ALTER mytable ADD UNIQUE [indexName] ON (username(length))

● 创建表的时候直接指定

SQL代码

CREATE TABLE mytable(
ID INT NOT NULL,
username VARCHAR(16) NOT NULL,
UNIQUE [indexName] (username(length))
);

（3）主键索引

它是一种特殊的唯一索引，不允许有空值。一般是在建表的时候同时创建主键索引：

SQL代码

CREATE TABLE mytable(
ID INT NOT NULL,
username VARCHAR(16) NOT NULL,
PRIMARY KEY(ID)
);

当然也可以用 ALTER 命令。记住：一个表只能有一个主键。

（4）组合索引

为了形象地对比单列索引和组合索引，为表添加多个字段：

SQL代码

CREATE TABLE mytable(
ID INT NOT NULL,
username VARCHAR(16) NOT NULL,
city VARCHAR(50) NOT NULL,
age INT NOT NULL
);

为了进一步榨取MySQL的效率，就要考虑建立组合索引。就是将 name, city, age建到一个索引里：

SQL代码

ALTER TABLE mytable ADD INDEX name_city_age (name(10),city,age);

建表时，usernname长度为 16，这里用 10。这是因为一般情况下名字的长度不会超过10，这样会加速索引查询速度，还会减少索引文件的大小，提高INSERT的更新速度。

如果分别在 usernname，city，age上建立单列索引，让该表有3个单列索引，查询时和上述的组合索引效率也会大不一样，远远低于我们的组合索引。虽然此时有了三个索引，但MySQL只能用到其中的那个它认为似乎是最有效率的单列索引。

建立这样的组合索引，其实是相当于分别建立了下面三组组合索引：

SQL代码

usernname,city,age
usernname,city
usernname

为什么没有 city，age这样的组合索引呢？这是因为MySQL组合索引“最左前缀”的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这三列的查询都会用到该组合索引，下面的几个SQL就会用到这个组合索引：

SQL代码

SELECT * FROM mytable WHREE username="admin" AND city="乌鲁木齐"
SELECT * FROM mytable WHREE username="admin"

而下面几个则不会用到：

SQL代码

SELECT * FROM mytable WHREE age=20 AND city="乌鲁木齐"
SELECT * FROM mytable WHREE city="乌鲁木齐"

（5）建立索引的时机

到这里我们已经学会了建立索引，那么我们需要在什么情况下建立索引呢？一般来说，在WHERE和JOIN中出现的列需要建立索引，但也不完全如此，因为 MySQL只对<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE才会使用索引。例如：

SQL代码

SELECT t.Name
FROM mytable t LEFT JOIN mytable m
ON t.Name=m.username WHERE m.age=20 AND m.city='乌鲁木齐'

此时就需要对city和age建立索引，由于mytable表的userame也出现在了JOIN子句中，也有对它建立索引的必要。

刚才提到只有某些时候的LIKE才需建立索引。因为在以通配符%和_开头作查询时，MySQL不会使用索引。例如下句会使用索引：

SQL代码

SELECT * FROM mytable WHERE username LIKE'admin%'

而下句就不会使用：

SQL代码

SELECT * FROM mytable WHEREt Name LIKE'%admin'

因此，在使用LIKE时应注意以上的区别。

（6）索引的不足之处

上面都在说使用索引的好处，但过多的使用索引将会造成滥用。因此索引也会有它的缺点：

● 虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数据，还要保存一下索引文件。

● 建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。

索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。

（7）使用索引的注意事项

使用索引时，有以下一些技巧和注意事项：

● 索引不会包含有NULL值的列

只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设计时不要让字段的默认值为NULL。

● 使用短索引

对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

● 索引列排序

MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

● like语句操作

一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

● 不要在列上进行运算

SQL代码

SELECT * FROM users WHERE YEAR(adddate)<2007;

将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成

SQL代码

SELECT * FROM users WHERE adddate< '2007-01-01';

● 不使用NOT IN和<>操作

NOT IN和<>操作都不会使用索引将进行全表扫描。NOT IN可以使用NOT EXISTS代替，id<>3则可以使用id>3 or id<3来代替。

--EOF--

本博客内部关于MYSQL索引的相关文章有：

MYSQL索引之小小分析

［分享］mysql数据库索引查询优化的分享

联合索引的经典例子

当然，对于索引，肯定要看MYSQL中EXPLAIN的说明

MYSQL汉字乱码的解决方案

gouki — 2010-05-15 11:27

其实以前也写过类似的东西，只是最近又有朋友在群里问我这样的事情，一时间在博客上没有找到，于是准备重写了一遍。

一般说来，我们所说的编码格式一致：可以如下图所示：character_set_client,character_set_connection,character_set_database,character_set_results,character_set_server编码要一致

初始情况的修改就是在my.ini里加上：default-character-set=utf8 【这个请使用适当的编码】

在程序中，我们如果是用mysql类库，往往都是在连接上后来运行：mysql_query("set names utf8")，这一句查询其实就是那句set character_set_connection=utf8, character_set_results=utf8, character_set_client=binary 的集合。

在PHP5的时候，如果你使用的mysql数据库版本大于5.0.7，你还可以用：mysql_set_charset这个方法直接定义。

所以，相对来说，处理乱码问题，参考这些就可以搞定了。

Facebook新开源项目Flashcache：加速MySQL

gouki — 2010-04-30 22:07

Facebook发布了通过将数据缓存在SSD硬盘加速MySQL的内核模块Flashcache。代码已经放到Github上，目前只测试了Linux kernel版本2.6.18和2.6.20。
Facebook 称，Flashcache是其内部开发用于帮助扩展InnoDB/MySQL数据库，但同时Flashcache也是作为一个通用的缓存模块设计的，因此能用在任何搭建在块设备之上的应用程序。

对于InnoDB，当工作集不与 InnoDB缓冲池一致，由于更多的工作集缓存在快速的媒介如固态硬盘上，将能显著的改进读取延迟。

--EOF--
没有测试，也无法测试，毕竟我没有SSD硬盘。纯新闻http://www.cnbeta.com/articles/109988.htm，突然发现，原来cnbeta的文章已经11万左右了

MySQL和SQL字段截短漏洞

gouki — 2010-04-25 12:12

这篇文章很有意思，以前注意过，但没仔细考虑过用来注入，或许就象王猛说的：

了解很长一段时间的web安全了，个人觉得世上最聪明的程序员其实是黑客，一次想N步，逻辑超强，技术全面，从操作系统漏洞、到语言本身漏洞、数据库本身漏洞、再到开发者代码，无孔不入。

文章来自寂寞hacker,http://hi.baidu.com/isbx/blog/item/08ef48547ef1ad58574e00bf.html:
当前的Web开发者中肯定有不少人没有注意到作者所提到的这两个问题的。

第一个问题是这样的，MySQL默认有一个配置参数 max_packet_size，这个参数是用于限制MySQL客户端和MySQL服务器端数据通信的数据包大小，MySQL的默认配置是1MB。如果客户端发送的数据超过了1MB，则MySQL服务器端会忽略掉这个请求数据。作者接下来举了两个利用这个缺陷的例子，第一个是利用超长数据来使MySQL的日志记录程序失效，第二个是在PHP+MySQL的环境下，PHP的Session清理程序会由于一次发送的清理session数据的请求数据包超过 max_packet_size的限制，而导致清理session失败。

而实际上，由于很多PHP+MySQL的程序都会运行用户上传附件之类，而一般的PHP+MySQL的上传附件限制都是大于1MB的，所以PHP的程序开发人员一般是会去修改max_packet_size的值为大于1MB。这就给我们的漏洞利用带来了一定的麻烦，毕竟在当前的网络状况下，构造 1MB多的数据去上传还是可以忍受的。但是太大的数据量就比较考验我们的耐心了，呵呵。

第二个问题就比较严重了，MySQL对于超过字段长度的数据插入操作会进行默认的字符串截短。例如一个字段定义的长度为10，如果插入的字符串长度超过10，MySQL会将长度超过10的部分字符串自动舍去后插入到数据表中。默认配置条件下，MySQL会产生一个警告信息，但是这个警告信息不会被 Web应用程序捕获到。所以，从表面上来看，超长数据也是可以“成功”插入数据表的。作者在下面举的这个例子就很有代表性了，首先是一个场景假设：

The application is a forum where new users can register
The administrator’s name is known e.g. ‘admin’
MySQL is used in the default mode
There is no application restriction on the length of new user names
The database column username is limited to 16 characters

用户如果尝试注册一个用户名为admin的用户，会由于Web应用程序中的isAlreadyRegistered函数的校验而注册失败。

SQL代码

SELECT * FROM user WHERE username='admin'

但如果用户使用用户名’admin x’来注册（注意admin和x之间有11个空格），则注册流程会是这样的：

isAlreadyRegistered函数会使用上面的SQL语句来检查user表中是否存在相同用户名的用户，查询结果肯定是不存在的。那么用户注册成功！

实际上，真正插入到user表中的用户名是’admin’！也就是说，MySQL不仅会截短超过长度限制部分的字符串，也会对字符串头尾的空白字符进行截短！所以，在user表中，现在存在了两个admin用户！

接下来，用户登陆，他使用的是用户名admin，密码是他刚才设置的’admin x’的密码。假设Web应用程序的登陆认证和授权函数是这样的一段代码：

PHP代码

$userdata = null;
if (isPasswordCorrect($username, $password)) {
$userdata = getUserDataByLogin($username);
...
}

其中isPasswordCorrect函数使用的SQL语句为：

SQL代码

SELECT username FROM users WHERE username = ? AND passhash = ?

getUserDataByLogin函数使用的SQL语句为：

SQL代码

SELECT * FROM users WHERE username = ?

可以看得出，上面的语句使用了预编译的SQL语句，是无法实施SQL注入的。但是由于MySQL的默认字段截短策略，isPasswordCorrect函数会成功执行并返回用户名admin，接下来的getUserDataByLogin也会正确执行，返回的结果虽然是一个数组，但是Web应用程序一般是取返回数组中的第一个结果，也就是真正的管理员用户admin的所有数据！

怎么样，不用SQL注入，一样拿到管理员权限！

后记：经过测试，上面的漏洞利用过程在MySQL 4中是确实存在并且可以利用的。但是在MySQL 5中，本机测试失败。失败的关键就在于MySQL 5对于超过字段长度限制的字符串插入会报错，并停止字符串插入操作。

附：MySQL 4的测试过程

SQL代码

mysql> select * from tb_sqltest where name='jason';
+----+-------+--------+------+------+------+------+
| id | name | remark | time | col1 | col2 | col3 |
+----+-------+--------+------+------+------+------+
| 1 | jason | NULL | NULL | NULL | NULL | NULL |
+----+-------+--------+------+------+------+------+
1 row in set
mysql> select * from tb_sqltest where name='jason x';
Empty set
mysql> insert into tb_sqltest (id,name) values (2,'jason x');
Query OK, 1 row affected
mysql> select * from tb_sqltest where name='jason';
+----+-------+--------+------+------+------+------+
| id | name | remark | time | col1 | col2 | col3 |
+----+-------+--------+------+------+------+------+
| 1 | jason | NULL | NULL | NULL | NULL | NULL |
| 2 | jason | NULL | NULL | NULL | NULL | NULL |
+----+-------+--------+------+------+------+------+
2 rows in set

有点意思：QQ 我的好友想到的信息架构

gouki — 2010-04-19 09:28

这篇文章有点意思，不过我更多的想的不是他所说的这种分类，一般来说，在电子商务里面这方面，这方面其实是最难界定的。产品A既可能属于B分类，也可能是属于C分类。但是在促销的时候，B分类产品不打折，C分类可以打折，这时你把A产品怎么处理？打折还是不打折？

QQ好友列表：

＋太原（9/39）
＋运城老乡（9/49）
＋西安（9）
＋学校（19）

问题：
QQ好友上新建了一个女孩组和一个西安组，上面的整理方式，发现经常弄错，比如“XX“同学，是我女友介绍认识的，我将她顺便放在太原组里面，后来知道她不在太原，山西运城人士，当我和她聊天时候，连我自己都很吃惊经常问，太原的一些情况，很是影响人家心情，搞的自己也很尴尬。
很长一段时间，渐渐习惯这种分类，突然间觉得这样的分类很不科学，很明显，这涉及SNS的经典问题，以及信息架构的经典问题：如何做一个有效分类？

我的需求：
1.      新添加一个朋友的时候固定存放
2.      常联系的人立马可以找到
3.      和我趣味相投的统统放在一起，玩到一起的，闲来没事可以出去一起疯狂的
4.      能够表达出我的职业规划，定位明确，可以清楚的阐述我的社会活动能力与人际关系

详细说明：

要做到：
1. 清楚地表现好友信息：一看这个分类，就知道这一类型的人是干什么的，和他们应该在那些方面可以顺利沟通清楚问题。
2. 层次结构清晰：一看这个分类，就知道什么人在这个分类下面，分类下面涉及到什么朋友

不应该是：
1.      这个分类给人一种距离感，陌生
2.      我想找的是分类A，但你却出现在分类B中？NND
3.      这个分类做出来不能让我自己都犯晕！

问题的表象是如何找到一个合理的好友分类方式，深入问题的本质，其实是不满足我的需求，而QQ体现的核心是我的二字，因此人际关系、社会活动能力、我的职业规划就是该信息架构问题的关键！这样就有了看似简单但能立刻解决问题的分类方式：

QQ好友列表：

＋熟人（9/19）
＋一家人（9/19）
＋一帮子（9/14）
＋光屁股长大（9/100）
+刚认识（2/10）
+xxx公司
+xxx公司

一切就这么简单，采用这个分类以后，立即心旷神怡！

--EOF--

原文来自：http://www.cnblogs.com/u_xiaomo/archive/2010/04/18/1714953.html

不过话说回来，抛开电子商务的因素，wordpress的分类设计的就是挺不错的。一篇文章在你迷惘的时候，可以放到多个分类里，分类又只是相当于一个标签。这样的设计让使用者也很爽。只是开发的时候累一点，SQL的性能差一点点而己。

两个比较常用的MySQL时间函数

gouki — 2010-04-14 11:20

这是来自iOrange.cc的文章，主要就讲了两个可能会被常用的时间函数。内容如下：

按时间搜索数据在mysql里应该是用的比较频繁的了。

iOrange系统里的时间都是按:xxxx-xx-xx xx:xx:xx这种格式存放的，大多数时候这个都没问题，但是，当你想使用其他格式来显示数据时就悲剧了，例如你想显示成 10/04/01 21:20 这种就很悲剧-__-，所以强烈建议保存时间戳的时候尽量存储一个UNIX时间戳，这样以后就方便很多了^_^

回归正题，第一个时间函数是：UNIX_TIMESTAMP，这个函数可以将xxxx-xx-xx xx:xx:xx这种格式的时间转换成一个unix时间戳格式的数字。例如下面那条语句：
update bookposts set lastpost = UNIX_TIMESTAMP(createdate) 这样就能将createdate字段上的时间更新到lastpost上去了。

第二个函数则跟第一个刚好相反：FROM_UNIXTIME，这个函数可以将一个UNIX时间戳转换成xxxx-xx-xx xx:xx:xx这种格式。用法大致如下：
SELECT COUNT(*) AS `newmembers` FROM `cdb_members` WHERE FROM_UNIXTIME(regdate, ‘%Y-%m-%d’) = ‘2010-04-01′”

--EOF--
不过，个人认为还是采用:xxxx-xx-xx xx:xx:xx比较好，这是因为，时间戳和这种日期格式在数据库里存储所占的字节都是一样的，而日期格式却没有1970~2038年这个限制。在计算时间区间的时候，用Between和and时，对于日期格式会更加方便，而时间戳则需要多计算一次。

参考：

1.Mysql时间函数 http://neatstudio.com/show-443-1.shtml

2.用TIMESTAMP类型取代INT和DATETIME[转] http://neatstudio.com/show-150-1.shtml

3.精通MYSQL数据库——连载八 http://neatstudio.com/show-263-1.shtml

公交车路线查询系统后台数据库设计

gouki — 2010-04-13 08:51

公交换乘一直以来是很让人头疼的问题。一般来说一次换乘还能相对比较简单，如果需要多次换乘那就复杂了。
在google map或者任意一个MAP上，你都可以选择从A点到B点的换乘方案，并且显示在地图上，抛开完整的数据库和大量的数据外，剩下的就是数据库设计了。

博客园有位作者写了几篇文章，可以为想入这行，或者想写类似程序的朋友做一点参考的。【我最初参考的一个什么叫龙腾还是啥来着的公交换乘软件的，它用的是access数据库，破解后直接看的数据库结构并进行反推的。那也是几年前的事情了】

这几篇文章中，有一篇讲的是步行的介入，可惜是纯代码，解释不多，但也能一看吧。

原文很长，我这里正好把几篇文章列出来，如此而己。。。。

以下文章将逐步深入地介绍公交车路线查询系统后台数据库的设计：

1.查询算法—— 实现站点到站点的换乘路线查询

2.关联地名和站点——实现通过地名或站点的路线查询

3.引入步行路线——在乘车路线中插入步行路线

4.换乘算法的改进与优化——改进原查询算法，提高其查询效率

如何清除mysql的mysql-bin日志

gouki — 2010-04-07 14:38

想把自己所有的数据打个包，结果才发现，原来我的目录居然有30多G，把曾给卖给别人的空间中的19G数据清除后，发现还有12G的软件数据，惊讶的要死，去看了一下，用的是懒宝宝的告诉我的命令：du -sh /xxxxx/
发现mysql/data下的数据居然有12G，想着怎么也不可能会有这么大的数据啊？仔细一看，原来这12G全是log文件。找了一些资料，才把这个log清除掉。。
方法如下：
第一种技巧：

XML/HTML代码

1 查询musql-bin,mysql操作日志
mysql> show master logs;
2 删除,保留最新
mysql>purge master logs to ‘mysql-bin.00001′;
3 my.cnf中去掉log-bin就可不让生成这些日志文件了。

第二种技巧：

XML/HTML代码

清理mysql的日志文件
发现var/db/mysql目录下有这么多
mysql-bin.000001
…
mysql-bin.000023
mysql-bin.index
而且比较大
数据库的操作日志
mysql> reset master;
可以清理这些文件。

这两种情况都可以，比较偏向于第一种，但我是因为要备份就直接用的第二种了。反正数据也没有出错过，资料来自于：http://www.tech-q.cn/thread-3198-1-1.html

Got error 28 from storage engine 解决方法

gouki — 2010-04-07 13:17

今天一大早，把我的数据都tar了一遍，结果。。。mysql数据库就出现了“Got error 28 from storage engine”错误，去google搜索了一下，发现问题这样解决;
1、

XML/HTML代码

磁盘临时空间不够导致。
解决办法：
清空/tmp目录，或者修改my.cnf中的tmpdir参数，指向具有足够空间目录

2、

XML/HTML代码

mysql报以下错的解决方法
ERROR 1030 (HY000): Got error 28 from storage engine
出现此问题的原因：临时空间不够，无法执行此SQL语句
解决方法：将tmpdir指向一个硬盘空间很大的目录即可

当然两个说法都是一样。所以基本肯定是空间没有了。去其他磁盘看了一下，果然。。
郁闷了一下，把备份文件先删除了就正常了。
两个技巧来自：http://www.aslibra.com/blog/read.php/794.htm，感谢这个google搜索的头条帮我解决了这个问题

Mysql分区表局限性总结

gouki — 2010-03-18 08:59

昨天晚上asers.z问我怎么样使得数据在搜索的时候和58.com差不多，而且展示数据的速度要快。我一直想着用mysql的分区表解决，而乔楚（乔大姐）则认为是采用sphinx来解决。
但后来我找了一个资料才发现，原来分区表还是有局限性的，比如他就不支持全文索引。我是看这里看到的。。

阅读全文

又见使用Guid做主键和int做主键性能比较的文章

gouki — 2010-01-04 21:08

关于使用GUID和INT做主键，性能差异的文章历来很多，不过。大多都是从理论上来说明，这次难得看到某人用PC机做测试，所以贴上来看看。但我不贴全文，毕竟。。。大量的代码贴上来，也没有太大的意义。所以仅贴上主体内容和测试结果，当然还会有一些用户的评论。。

原文网址为：http://www.cnblogs.com/jackhuclan/archive/2010/01/04/1639005.html
内容大致如下，【如想看全文，请使用上面的链接】
在数据库的设计中我们常常用Guid或int来做主键，根据所学的知识一直感觉int做主键效率要高，但没有做仔细的测试无法说明道理。碰巧今天在数据库的优化过程中，遇到此问题，于是做了一下测试。

测试环境：

　　台式电脑 Pentiun(R) 4 Cpu 3.06GHz
Win XP professional
1.5G DDR RAM
SQL Server 2005 个人版

测试过程：
首先创建测试数据库Test
1.创建Test_Guid表，创建Test_Int表
2.创建Test_Guid子表：Test_Guid_Detail和创建Test_Int子表：Test_Int_Detail，用来做连接查询
3、然后进行一些CRUD的操作【这是我写的，因为原文中写插入N行数据，删除N行数据之类的太复杂，也太多，简化为一句话了】

测试结果如下：

综上所述，使用int做主键比用guid做主键各中情况下效率均有提高，特别是在有连接查询和删除记录效率提升明显。

而且本人今日在guid做主键的数据查询中因为嵌套几个子查询结果屡屡出现查询超时。因此本人赞同用int做主键，不赞同guid做主键。
以上观点代表个人观点，欢迎大家各抒己见，说明guid和int各自做主键的优劣所在。

----EOF---

本来到这里就可以结束了，但有一个用户的评论还算不错：

徐少侠

首先
10万行不算大数据量
我测试插入操作的时候是1600万行。性能约有10-20%的差异
当然，10万行也能说明一些问题了
其次，请在所有的where和on条件中使用到的列身上增加一个索引
也就是说所有的外键都要有索引，非唯一索引
具体说，就是主表的TestId以及子表对应的外键列
然后再重新执行一下上述测试
主要对带where和inner join的测试表示疑问
最后，int在多数情况下一定比Guid快，这是不用怀疑的。
同时，查询优化主要靠索引，以及对索引树的优化以及查询顺序的安排
主键的数据类型一般只影响到插入操作的速度
对于查询操作的影响是比较小的
不至于出现50%左右的性能差异

更多的人认为GUID在做数据迁移的时候很方便，而如果使用INT则会有意料不到的问题。而GUID遇到的问题会少很多。。。

相对于以上的观点我还是比较认同的，但我认为性能相差这么大是有可能有以下的原因：
1、作者用的是PC机
2、操作系统是XP
3、sql server 是个人版【我没有试用服务器版性能如何，但我想，一定比个人版性能更优，当然这是猜测】

说归说，对于MYSQL来说，基本上还是只能使用INT做主键。毕竟MYSQL没有自带的生成GUID的方法【我不是指手动生成，我是说自动生成。。。UUID()函数是可以生成GUID的，但不能象INT那样自动插入，也没有办法设置default为UUID()方法】

看51CTO上两篇MYSQL引擎该如何选择的文章

gouki — 2010-01-03 13:21

MYISAM和INNODB的争论由来已久，如今，我又找到两篇文章，让我们看看有关这两种引擎的优劣的文章：浅谈MySQL存储引擎选择 InnoDB还是MyISAM以及InnoDB还是MyISAM 再谈MySQL存储引擎的选择

第一篇：浅谈MySQL存储引擎选择 InnoDB还是MyISAM

作者：酷壳，来源于：http://database.51cto.com/art/200905/122382.htm

MyISAM 是MySQL中默认的存储引擎，一般来说不是有太多人关心这个东西。决定使用什么样的存储引擎是一个很tricky的事情，但是还是值我们去研究一下，这里的文章只考虑 MyISAM 和InnoDB这两个，因为这两个是最常见的。

下面先让我们回答一些问题：
◆你的数据库有外键吗？
◆你需要事务支持吗？
◆你需要全文索引吗？
◆你经常使用什么样的查询模式？
◆你的数据有多大？

思考上面这些问题可以让你找到合适的方向，但那并不是绝对的。如果你需要事务处理或是外键，那么InnoDB 可能是比较好的方式。如果你需要全文索引，那么通常来说 MyISAM是好的选择，因为这是系统内建的，然而，我们其实并不会经常地去测试两百万行记录。所以，就算是慢一点，我们可以通过使用Sphinx从 InnoDB中获得全文索引。

数据的大小，是一个影响你选择什么样存储引擎的重要因素，大尺寸的数据集趋向于选择InnoDB方式，因为其支持事务处理和故障恢复。数据库的在小决定了故障恢复的时间长短，InnoDB可以利用事务日志进行数据恢复，这会比较快。而MyISAM可能会需要几个小时甚至几天来干这些事，InnoDB 只需要几分钟。

您操作数据库表的习惯可能也会是一个对性能影响很大的因素。比如： COUNT() 在 MyISAM 表中会非常快，而在InnoDB 表下可能会很痛苦。而主键查询则在InnoDB下会相当相当的快，但需要小心的是如果我们的主键太长了也会导致性能问题。大批的inserts 语句在MyISAM下会快一些，但是updates 在InnoDB 下会更快一些——尤其在并发量大的时候。

所以，到底你检使用哪一个呢？根据经验来看，如果是一些小型的应用或项目，那么MyISAM 也许会更适合。当然，在大型的环境下使用MyISAM 也会有很大成功的时候，但却不总是这样的。如果你正在计划使用一个超大数据量的项目，而且需要事务处理或外键支持，那么你真的应该直接使用InnoDB方式。但需要记住InnoDB 的表需要更多的内存和存储，转换100GB 的MyISAM 表到InnoDB 表可能会让你有非常坏的体验。

第二篇：InnoDB还是MyISAM 再谈MySQL存储引擎的选择

作者：邵宗文，来源于：http://database.51cto.com/art/200905/124370.htm

两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。

我作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，但是从我目前运维的数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是我的首选。

原因如下：

1、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。

2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。

3、从平台角度来说，经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候 MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的 binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为我平台上最小的一个数据库实例的数据量基本都是几十G大小。

4、从我接触的应用逻辑来说，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的60%以上的操作，而这种操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是 where对它主键是有效，非主键的都会锁全表的。

5、还有就是经常有很多应用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。

6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。

7、如果是用MyISAM的话，merge引擎可以大大加快应用部门的开发速度，他们只要对这个merge表做一些select count(*)操作，非常适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。

当然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台应用出发，我还是会首选MyISAM。

另外，可能有人会说你MyISAM无法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天十多亿 pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。

文章都不太长，适合着看看就行了。。

【笔记】MySQL忘记密码解决方案

gouki — 2009-12-25 09:45

本以为自己用不上这类东西，因为自己的密码几乎都记得。然而经验是没有用的。我确实就忘记了密码。还好有google。找到了这篇：

http://www.91linux.com/html/article/database/mysql/20090330/16283.html

在windows下：
打开命令行窗口，停止mysql服务：Net stop mysql
到mysql的安装路径启动mysql，在bin目录下使用mysqld-nt.exe启动，在命令行窗口执行：mysqld-nt --skip-grant-tables
然后另外打开一个命入令行窗口，执行mysql，此时无需输入密码即可进入。
>use mysql
>update user set password=password("new_pass") where user="root";
>flush privileges;
>exit
使用任务管理器，找到mysqld-nt的进程，结束进程！
在重新启动mysql-nt服务，就可以用新密码登录了。
在linux下：
如果 MySQL 正在运行，首先杀之： killall -TERM mysqld。
启动 MySQL ：bin/safe_mysqld --skip-grant-tables &
就可以不需要密码就进入 MySQL 了。
然后就是
>use mysql
>update user set password=password("new_pass") where user="root";
>flush privileges;
重新杀 MySQL ，用正常方法启动 MySQL 。

可惜，在linux下好象不太正确。当然或许我用的是ubuntu的关系。。

找了一下，找不到safe_mysqld，于是我进入/etc/init.d/目录，打开mysql文件，查看了一下里面安全启动的文件发现居然是mysqld_safe。郁闷了一下。。。

作个笔记。

dbanotes.net：数据分片(Sharding)设计问题一例

gouki — 2009-12-10 12:35

正如本文的最后一句话：对于数据量不大的站点，首选如何利用好 Cache 吧，分片只是手段，不是目的。事实上，如果不是涉及到每天上万的交易量，Cache才是更好的处理方案。当然象文中回答的对象来自腾讯，那当然，对于拍拍网、Q币等交易，几乎每天都是过万的交易量，这时候他们才会考虑使用所谓的数据分片。不过，了解一下这种技术或者说是手段，出去IB一下的时候也可以吹吹啊。。

原文来自：http://www.dbanotes.net/database/sharding.html，全文如下【未作删节】：
作者: Fenng

Question：假设一家 C2C 网站，数据库中某表存储买卖双方交易的数据信息，对于一条交易来说，买卖双方数据具有一定程度的耦合性，比如卖家的状态更新对应买家的状态也会更新，对于一个中大规模的电子商务网站，架构师在设计中如何考虑数据分片的问题（假定该表随着数据的膨胀必须拆分)?

Answer：对于一个中大规模的电子商务网站，随着网站的不断发展，其相应的数据规模会不断膨胀。数据分片技术是使网站得于实现可扩展性的一种常用解决方案。对于 C2C 类型的网站，由于交易记录不容易进行水平的数据分割，因此对于这样的应用处理要再进行细分：

买卖双方交易的信息，具备较高的时效性，即交易全部完成后就不会再有更新，因此这部分数据可以与正在交易中的数据区分开来，并可以单独分表，定时归纳。具体的做法可以采用水平分割的数据分片技术，比如可以根据用户号码段范围进行切片，把不同的群体划分到不同的 DB 上，这样可以很好的进行横向水平扩展（Scale Out）。它可以很好的突破单节点数据库服务器的 I/O 能力限制，解决数据库扩展性问题。
对于正在交易中的数据，主要根据时间进行分表。如果分的更细，则可以分三个表，但是这样在事务保证方面则要复杂很多，不建议这样做。

这个问答是《程序员》杂志架构师接龙栏目的第一期的内容。提问者是我，回答者是腾讯研发总监王速瑜先生。其实我抛出问题后当时还真不知道接龙的是哪位，只是知道会是百度或是腾讯的朋友来回答，当然我也对这两家的数据处理方式都是比较感兴趣的。最后刊登的内容或许让很多人觉得不过瘾 -- 如果能更详细一点就好了(毕竟还有其他问题呢)。不过能够引发思考就好，这也是这个栏目的初衷吧。

对这个问题或许可以补充的是，切分或许还算是容易的事情，但是切分后用户对数据的查询多少是有点麻烦。一旦要查询历史交易信息，则必须考虑跨多个数据分片获取数据并排序的问题。交易中的数据与交易完成的数据是否做切分，是有必要根据自己的实际情况仔细衡量。要注意如对交易中的活动数据单独存放的一个表中，则还是不可避免的要产生 I/O 热点问题，而且，这个表实际上变成了一个数据队列(新的瓶颈)--新生成的交易进来，完成的交易删除或归档。这样产生的双重 I/O 压力不容忽视。

当然，这个问题的前提限制了回答的发挥，其实在设计初期也可以考虑买家信息与卖家信息分别放入不同的表中，然后对这两种属性的表再进行切分，这也是可选的途径，这样的开销是每笔交易会重复存储一条记录，而记录的变化也要在两个表中更新。对数据的一致性维护有一定的挑战。这似乎是个只带来额外开销的办法？其实也有益处--索引的设计起码会更简单一些，而用户对交易记录的定制查询也会更加方便。

数据分片(或 Sharding) 现在几乎是每个网站架构师都必须要考虑的基础问题。多数情况下，分片的粒度和方式取决于业务，慢慢地快变成可意会不可言说的话题了，你有什么建议或意见不妨留言说说。

--EOF--

为了避免误导，对于数据量不大的站点，首选如何利用好 Cache 吧，分片只是手段，不是目的。【这句话也是dbanotes.net所提出的。不是我说的，虽然我也是这个想法。。。黑黑】

[MySQL FAQ]系列 -- 账号密码包含反斜线时怎么办

gouki — 2009-10-15 18:03

本文来自mysql中文网，看文章的内容就知道作者是谁了啦。呵呵。反斜框做密码还没有使用过。。

原文如下：

问：如果密码中包含反斜线，该如何处理呢？
答：在mysql中，反斜线"\"是有特殊意义的，用于转义，因此如果密码中包含"\"，就需要特别注意。有一种一劳永逸的办法，就是在密码中不用反斜线，哈哈。另一种，那就是需要多加几个反斜线，例如：

(root:hostname:Thu Oct 15 09:15:38 2009)[mysql]> grant usage on *.* to yejr@localhost identified by 'ye\\\jr'; 
Query OK, 0 rows affected (0.02 sec)
(root:imysql.cn:Thu Oct 15 09:16:22 2009)[mysql]> select password('ye\jr');
+-------------------------------------------+
| password('ye\jr')                         |
+-------------------------------------------+
| *9DB91006131E32B22135599033C6A9C196EC3C6B | 
+-------------------------------------------+
1 row in set (0.00 sec)
(root:imysql.cn:Thu Oct 15 09:23:32 2009)[mysql]> select host,user,password from user where user='yejr';         
+-----------+------+-------------------------------------------+
| host      | user | password                                  |
+-----------+------+-------------------------------------------+
| localhost | yejr | *F06D79D5F57894772B64BF3164ABB714EBDBD3E2 | 
+-----------+------+-------------------------------------------+
1 row in set (0.01 sec)
(root:imysql.cn:Thu Oct 15 09:16:28 2009)[mysql]> select password('ye\\\jr');
+-------------------------------------------+
| password('ye\\\jr')                       |
+-------------------------------------------+
| *F06D79D5F57894772B64BF3164ABB714EBDBD3E2 | 
+-------------------------------------------+
1 row in set (0.01 sec)
[@tc_10.11.54.224_cnc ~]# mysql -uyejr -p'ye\jr'
Logging to file '/home/mysql/query.log'
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 63
Server version: 5.x.x-percona-highperf-x-log MySQL Percona High Performance Edition (GPL)
Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.
原贴地址：http://imysql.cn/2009/03/25/mysql-faq-password-with-slash.html
作者：yejr

(yejr:imysql.cn:Thu Oct 15 09:24:58 2009)[(none)]> Bye

从上面的例子可以看到，如果密码中有反斜线，就需要在它前面再加2个反斜线。

MySQL前CEO致信欧盟请求批准甲骨文Sun交易

gouki — 2009-10-09 15:41

没有了mysql我们还有什么？
其实没有了mysql还有很多数据库可用，有小型的sqlite，有和mysql性能差不多的postgresql等

但mysql是用了最方便的。phpmyadmin使得许多不懂数据库的人也会操作了。。。

以下是原文：
来自于：http://www.cnbeta.com/articles/95165.htm

美国开源数据库厂商MySQL前CEO马顿·古斯塔夫·米科斯(Marten Gustaf Mickos)周四致信欧盟,要求欧盟尽快批准美国商用软件开发商甲骨文收购服务器和软件开发商Sun的交易.
2008年1月,MySQL被Sun收购,并成为后者数据库业务部门.甲骨文今年4月宣布,将以74亿美元收购Sun.此前Sun股东和美国司法部已批准该交易,但欧盟仍在对此展开反垄断调查.按照原定计划,欧盟将于明年1月19日宣布是否批准甲骨文-Sun交易.

米科斯周四在写给欧盟反垄断专员尼莉·克罗斯(Neelie Kroes)的信件中表示,欧盟对甲骨文收购Sun及其开源数据库软件是否将危害市场一事展开调查,这本身无疑是正确的决定,但甲骨文-Sun交易本身其实不会妨碍正常市场竞争.

米科斯在信中写道:“如果该交易存在不确定因素,将给Sun各项业务正常发展带来负面影响,同时使市场竞争程度有所降低.正因为如此,如果甲骨文-Sun交易被迫推迟,则其后果将同欧盟的良好愿望背道而驰.”

米科斯还在信中阐述了欧盟应尽早批准甲骨文-Sun交易的两大理由:1)与Sun当初收购MySQL后会继续保留后者业务一样,甲骨文完成同Sun交易后,同样也会继续保留和进一步发展MySQL业务.2)退一步说,即使甲骨文今后对MySQL存在偏见(实际上不太可能),由于MySQL本身市场影响力很大,因此甲骨文一家公司并不具备完全“扼杀”MySQL的能力.

业界人士表示,目前还不清楚米科斯提交这封信件后,是否会对欧盟的相应决定带来影响.但无论如何,作为MySQL的前CEO,米科斯对MySQL的具体业务可谓了如指掌.

此前米科斯已加盟美国风险投资机构Benchmark Capital.他近日在接受外界采访时表示,由于已经不再负责MySQL管理工作,因此甲骨文-Sun交易被批准后,自己并不会从交易中获得任何利益; 他之所以要致信欧盟,是想让Sun及MySQL部门员工受益.2008年Sun提出收购MySQL时,米科斯曾加以拒绝,但后来转变态度而答应Sun收购请求.

甲骨文CEO拉里·埃里森(Larry Ellison)此前称,MySQL会在不同业务领域同甲骨文现有数据库产品争抢市场.他还表示,甲骨文今后不会把MySQL分拆为独立公司.

MySQL的1067错误解决方案大全

gouki — 2009-09-16 16:57

本文乃是从google搜索而来，缘由是有群友问，1067怎么处理。。。
于是google了一下，因为我记得好象是没有指定default_file。。
结果，发现1067错误有这么多的原因啊？来源于：http://www.wzsky.net/html/Program/Mysql/100436.html

原文如下：

本文例举了MySQL的1067错误的多种解决方法，以便大家遇到该错误时可以快速参考解决。

内容：
*************
1

安装MYSQL后更改了ROOT的密码后用
net startmysql
启动时我就遇到了这样的问题．使用以下命令后
c:\mysql\bin\mysqladmin-u root -p shutdown
再net start mysql就没有这个错误提示了!

*************
2
MySQL的1067错误

Q：我的Mysql碰到了 1067 错误

错误信息为：
A system error has occurred.
System error 1067 has occurred.
The process terminated unexpectedly.

A：在我的机上的解决办法是：
修改%windir%\my.ini，增加
[mysqld]
#设置basedir指向mysql的安装路径
basedir=D:\Program\Tools\mysql
datadir=D:\Program\Tools\mysql\data

*************
3
已经弄好了!!!
好像是这样……
mysql_install_db 脚本只是在初次安装时才需要运行一次,之后就不用再运行了,不知道是不是这么回事.我把mysql.server拷贝至/etc/rc.d/init.d /中,运行chkconfig mysql.server,至此mysql服务器每次开机自动启动,只要设置好PATH,在命令行上输入mysql就一切搞定!
看来摸索的过程实在是痛苦啊,这已经折磨我好几天了……

*************
4

问：我的Mysql碰到了 1067 错误

错误信息为：

A system error has occurred.
System error 1067 has occurred.
The process terminated unexpectedly.

答：
解决办法：

1.检查你的Mysql目录有没有给系统的System用户权限。
2.删除掉你的 %WINDOWS%/my.ini 文件。
3.检查你的 c:/my.cnf 文件配置是否正确。

*************
5

【☆☆☆ MySql概要说明 ☆☆☆】
MySql 的默认安装目录是c:mysql，安装结束后没有任何提示信息说安装结束，请点Finish按钮之类的话，直接就退出了。如果需要安装到其他目录，建议先安装到c:mysql，然后再整个目录move到自己希望的地方，例如移动到d:mysql 之后，需要编辑 d:mysqlmy-example.cnf （*.cnf的文件在Windows 2000中会被注册成为 SpeedDial文件，在资源管理器中无法操作，要用命令行来启动notepad编辑，例如运行notepadd:mysqlmy- example.cnf ，但是这个文件是UNIX系统下的文本文件格式，在notepad中不能正确换行，可以用write打开编辑，
或者用write打开后保存一次，再用notepad就可以编辑了。）找到basedir一行，去掉前面的“#”号注释，将后面的路径改为移动后的目录（目录分隔符要用斜线而不是反斜线），然后另存为：c:my.cnf
用服务方式启动的MySql如果用 net stop mysql 来停止，会得到一条出错消息，例如：
C:>net stop mysql
MySql 服务正在停止.
系统出错。
系统发生 1067 错误。
进程意外终止。
MySql 服务已成功停止。
这没有关系，MySql确实已经停止了。但是假如不希望看到任何出错消息
的话，可以用以下的命令来停止：
C:>mysqlbinmysqladmin -u root shutdown
如果没有任何提示信息，说明MySql已经成功停止了。
需要说明的是MySql虽然号称安装简单，易于使用，但是这毕竟是基于SQL的数据库管理系统，所以如果不是对SQL十分精通的话恐怕也不能拿它来做什么

**************
6

mysql服务无法启动的解决方法
mysql服务无法启动

我的操作系统是 win xp
无论安装何版本的mysql，在管理工具的服务中启动mysql服务时都会在中途报错
内容为：在本地计算机无法启动mysql服务错误1067：进程意外中止

经过多方求教，得解决方法如下

查找系统(后来验证应该为windows目录)目录下的my.ini文件，编辑内容（如果没有该文件，则新建一个），至少包含basedir，datadir这两个基本的配置。
[mysqld]
# set basedir to installation path, e.g., c:/mysql
# 设置为MYSQL的安装目录
basedir=D:/www/WebServer/MySQL
# set datadir to location of data directory,
# e.g., c:/mysql/data or d:/mydata/data
# 设置为MYSQL的数据目录
datadir=D:/www/WebServer/MySQL/data

另外，要主意
[WinMySQLadmin]
Server=D:/www/WebServer/MySQL/bin/mysqld-nt.exe
user=root
password=xxxxxxxx
#以上是设置WinMySQLadmin的配置
[Client]
user=root
password=xxxxxxxx

hehe~ 解决了

**************
7
刚刚弄好Mysql 『关键字 1067错误』
比较郁闷，竟然没有想到安装个Mysql也会出错，错误代码是1067 安装卸载了好几次，就是不行，而且把一些禁用了的服务都打开了，但是还是不行。最后我是这样解决的：

在C:\windows里找一找my.ini 然后删除然后再启动winmysqladmin.exe界面配置mysql，保存my.ini就可以了启动mysql试试呵呵

***************
8
mysql 错误 1067: 进程意外终止
这个问题困扰了一个早晨，非常郁闷！以前我在装mysql的时候从来没有遇到过，可是现在庄这个高版本的就有问题了，我换我装过的低版本的还是一样的问题（最关键的是操作系统都是一样的）。在windows2000的服务里面启动mysql服务可是总是弹出“错误 1067: 进程意外终止”！

我感觉问题在配置文件，于是就重新写了my.ini，启动还是一样的效果，我在google上查找无果，崩溃状态！就在此时眼前一亮，一位高人的指点是我豁然开朗，你的ini文件有否放到windows目录下，我从个人目录的windows目录下，将其拷贝到系统windows目录下，启动服务，ok!!!

叶金荣的MYSQL优化PPT

gouki — 2009-09-03 09:53

原来的PPT是在线的，由slideshare提供，网址为：http://www.slideshare.net/secret/IzjEa4qGWlMeLH，不过为了方便大家下载，并使用PPT观看，我还是做了一下本地备份。

因为，我看到了PPT中每个页面下面基本上都有注释，而线上的版本是不存在注释的。所以。尽量还是下载回本地看吧？

使用wps或者office 2007观看。

附件: mysql20090828-090831223515-phpapp01.pptx (1.38 M, 下载次数:690)

Query Cache，看上去很美

gouki — 2009-08-27 22:02

query cache在开发中应该算是应用的挺广泛的。但事实上，在高并发网站，query cache是应该并关闭的（我是指论坛、SNS类型的网站），而应该用其他的方式进行缓存，不是用数据库。
众所周知，在设置了query cache后，连续的查询同样的sql，那么这些SQL是会被缓存下来的，然而一旦有更新cahce会被清空。数据量小的时候可能感觉不出来，如果数据量大了，其实反而是影响效率的。因此一般不太会使用。。

mysql的参数是：

XML/HTML代码

# Query cache is used to cache SELECT results and later return them
# without actual executing the same query once again. Having the query
# cache enabled may result in significant speed improvements, if your
# have a lot of identical queries and rarely changing tables. See the
# "Qcache_lowmem_prunes" status variable to check if the current value
# is high enough for your load.
# Note: In case your tables change very often or if your queries are
# textually different every time, the query cache may result in a
# slowdown instead of a performance improvement.
query_cache_size=0

taobao DBA的苏普说：

当你的数据库打开了Query Cache（简称QC）功能后，数据库在执行SELECT语句时，会将其结果放到QC中，当下一次处理同样的SELECT请求时，数据库就会从QC取得结果，而不需要去数据表中查询。

在这个“Cache为王”的时代，我们总是通过不同的方式去缓存我们的结果从而提高响应效率，但一个缓存机制是否有效，效果如何，却是一个需要好好思考的问题。在MySQL中的Query Cache就是一个适用较少情况的缓存机制。在上图中，如果缓存命中率非常高的话，有测试表明在极端情况下可以提高效率238%^[1]。但实际情况如何？Query Cache有如下规则，如果数据表被更改，那么和这个数据表相关的全部Cache全部都会无效，并删除之。这里“数据表更改”包括: INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE, DROP TABLE, or DROP DATABASE等。举个例子，如果数据表posts访问频繁，那么意味着它的很多数据会被QC缓存起来，但是每一次posts数据表的更新，无论更新是不是影响到了cache 的数据，都会将全部和posts表相关的cache清除。如果你的数据表更新频繁的话，那么Query Cache将会成为系统的负担。有实验表明，糟糕时，QC会降低系统13%^[1]的处理能力。

如果你的应用对数据库的更新很少，那么QC将会作用显著。比较典型的如博客系统，一般博客更新相对较慢，数据表相对稳定不变，这时候QC的作用会比较明显。

再如，一个更新频繁的BBS系统。下面是一个实际运行的论坛数据库的状态参数：

QCache_hit	5280438
QCache_insert	8008948
Qcache_not_cache	95372
Com select	8104159

可以看到，数据库一共往QC中写入了约800W次缓存，但是实际命中的只有约500W次。也就是说，每一个缓存的使用率约为0.66次。很难说，该缓存的作用是否大于QC系统所带来的开销。但是有一点是很肯定的，QC缓存的作用是很微小的，如果应用层能够实现缓存，将可以忽略QC的效果。

————-下面是关于QC的一些其他细节—————–

一、Query Cache相关参数：

query_cache_size QC占用空间大小，通过将其设置为0关闭QC功能
query_cache_type 0表示关闭QC；1表示正常缓存；2表示SQL_CACHE才缓存
query_cache_limit 最大缓存结果集
query_cache_min_res_unit 手册上说，QC会按照这个值分配缓存block的大小。
Qcache_lowmem_prunes 这是一个状态变量(show status)，当缓存空间不够需要释放旧的缓存时，该值会自增。

二、Query Cache观察：

CREATE TABLE t1(id INT,var1 varchar(10));
	//Com_select:8	Qcache_hits:1
INSERT INTO t1 VALUES(1,’WWW’);
	//Com_select:8	Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
	//Com_select:9	Qcache_hits:1
SELECT * FROM t1 WHERE id=1;
	//Com_select:9	Qcache_hits:2 Qcache_queries_in_cache:1
INSERT INTO t1 VALUES(2,’RRRR’);
	//Com_select:9	Qcache_hits:2 Qcache_queries_in_cache:0
SELECT * FROM t1 WHERE id=1; //INSERT后Cache失效
	//Com_select:10  Qcache_hits:2 Qcache_queries_in_cache:1

参考：

(全文完)

本文引用地址为：http://rdc.taobao.com/blog/dba/html/325_query-cache-cool-or-not.html

字符与字节

gouki — 2009-08-27 14:29

对于数据库来说，开发人员可能更多的属于不明真相的围观群众这类人。对于字段长度或许都有所了解，对于不同的字符集所占的位数也会明白一些，但究竟是不是你想象的那样，你又真的了解多少？

看看人家玄月写的文章吧。不要不承认，其实你我都一样，都是知其然不知其所以然，而且都是看着书然后人云亦云。有时候不测试不亲自动手是看不到真相的。当然我也仅转载。我也没有测试，其实我就在真相门外徘徊。

原文如下：

字符与字节的问题
1、表t1
mysql> show create table t1\G
*************************** 1. row ***************************
Table: t1
Create Table: CREATE TABLE `t1` (
`a` char(1) DEFAULT NULL,
`b` binary(1) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=gbk

1）插入数据：
mysql> insert into t1 values(’w',’w'),(’中’,'中’);

mysql> select * from t1;
+——+——+
| a | b |
+——+——+
| w | w |
| 中 | ? |
+——+——+

2）插入数据被截断:
mysql> insert into t1 values(’xy’,'xy’),(’中国’,'中国’);
Query OK, 2 rows affected, 4 warnings (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 4

mysql> select * from t1;
+——+——+
| a | b |
+——+——+
| w | w |
| 中 | ? |
| x | x |
| 中 | ? |
+——+——+

2、表t2
mysql> show create table t2\G
*************************** 1. row ***************************
Table: t2
Create Table: CREATE TABLE `t2` (
`a` char(2) DEFAULT NULL,
`b` binary(2) DEFAULT NULL
) ENGINE=InnoDB DEFAULT CHARSET=gbk

1）插入数据：
mysql> insert into t2 values(’w',’w'),(’中’,'中’);
Query OK, 2 rows affected (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 0

mysql> select * from t2;
+——+——+
| a | b |
+——+——+
| w | w |
| 中 | 中 |
+——+——+
2 rows in set (0.01 sec)

mysql> insert into t2 values(’xy’,'xy’),(’中国’,'中国’);
Query OK, 2 rows affected, 1 warning (0.00 sec)
Records: 2 Duplicates: 0 Warnings: 1

mysql> select * from t2;
+——+——+
| a | b |
+——+——+
| w | w |
| 中 | 中 |
| xy | xy |
| 中国 | 中 |
+——+——+

总结： char以字符来计算，一个中文一个英文都是占1个字符；
Binary以字节来计算，一个英文占1个字节，一个中文占2个字节。

原文地址：http://rdc.taobao.com/blog/dba/html/324_%e5%ad%97%e7%ac%a6%e4%b8%8e%e5%ad%97%e8%8a%82.html

TaobaoDBA的一些关于INNDB的文章

gouki — 2009-08-18 15:14

淘宝DBA最近发力挺多的。很多关于innodb和myisam等数据库格式的性能测试。
不信？看图吧。

看到这么多，你还能怎么说？还不上去看看？

本来想一一截取下来做记录的，但是发现太多了。呵呵，请自己上线看吧。

网址为：http://rdc.taobao.com/blog/dba

我会采用ScrapBook抓取一份，然后打个包上传，如果有人使用ScrapBook，可以直接导入。

文件地址为：

scrapbook.rar

Wordpress MYSQL数据库优化技巧

gouki — 2009-07-21 16:34

一直在考虑是不是要换到wordpress, sablog用了这么长时间，也算是有感情了的。只是，他一直不更新，而且前台模板用的那种定界符做模板处理，我很不习惯。
以前coolcode.cn也是用的wordpress，后来转到了sablog上面。如今，我却想转到wordpress上面。。。不知道是进步还是退步。

也曾想过重写前台，请了两个朋友帮我做页面，结果现在是程序写了一半，页面做了一半，离完成看来是遥遥无期了。。

所以，记录下这个文章，方便以后真的要转换的时候，也能做个参考。。

阅读全文

taobaoDBA关于MyISAM和InnoDB的插入性能的测试

gouki — 2009-07-14 07:10

innodb和myisam两种类型的表，是mysql的基础表。很多人为了选择该使用哪种表而头疼。
一般来说innodb对事务的支持比较好，而myisam则一般，innodb是行锁,mysql是表锁。但。。。下面这个测试却：
原文：http://rdc.taobao.com/blog/dba/html/295_insert_benchmark_for_myisam_and_innodb.html
作者：陶方
内容：

测试表结构：
CREATE TABLE `test` (
`ID` bigint(20) NOT NULL auto_increment,
`INT_A` int(11) default NULL,
`INT_B` int(11) default NULL,
`INT_C` int(11) default NULL,
`STRING_A` varchar(50) default NULL,
`STRING_B` varchar(250) default NULL,
`STRING_C` varchar(700) default NULL,
PRIMARY KEY (`ID`),
KEY `IDX_TEST_IA` (`INT_A`),
KEY `IDX_TEST_IB` (`INT_B`),
KEY `IDX_TEST_SA` (`STRING_A`,`INT_C`)
) ;

数据量：总共10个表，每个表插入400w数据
并发数：每个表并发20个线程去执行插入操作，总共200个线程
数据特点：除了主键采用自增外，索引相关字段全是随机生成的。字符串的长度和内容都是随机的，平均长度为预定义的一半



X轴是unix时间戳，Y轴是十秒钟的插入量。从以上测试结果可以看出，InnoDB的插入性能随着数据量的增多一直在下降，而且表现相当不稳定。MyISAM的表现还是比较好的，虽然瞬时插入的谷值一直在下降，但是整体表现很稳定。
总的来说，Ext3的cache算法性能还是非常不错的，不愧是linux上面备受推崇的文件系统。InnoDB虽然提供了高可用性，但是插入性能方面的表现并不如MyISAM稳定。

--EOF--
对于这个图是什么生成的，我也很有兴趣。。。。目前未知

mysql命令行常用命令

gouki — 2009-07-09 07:19

这是某人整理的东西，发现还是挺有用的。。

它来自于PHP博客，看着挺有用。值得摘抄

mysql命令行常用命令

第一招、mysql服务的启动和停止
net stop mysql
net start mysql

第二招、登陆mysql
语法如下： mysql -u用户名 -p用户密码
键入命令mysql -uroot -p，回车后提示你输入密码，输入12345，然后回车即可进入到mysql中了，mysql的提示符是：
mysql>
注意，如果是连接到另外的机器上，则需要加入一个参数-h机器IP

第三招、增加新用户
格式：grant 权限 on 数据库.* to 用户名@登录主机 identified by "密码"
如，增加一个用户user1密码为password1，让其可以在本机上登录，并对所有数据库有查询、插入、修改、删除的权限。首先用以root用户连入mysql，然后键入以下命令：
grant select,insert,update,delete on *.* to user1@localhost Identified by "password1";
如果希望该用户能够在任何机器上登陆mysql，则将localhost改为"%"。
如果你不想user1有密码，可以再打一个命令将密码去掉。
grant select,insert,update,delete on mydb.* to user1@localhost identified by "";

第四招：操作数据库
登录到mysql中，然后在mysql的提示符下运行下列命令，每个命令以分号结束。
1、显示数据库列表。
show databases;
缺省有两个数据库：mysql和test。 mysql库存放着mysql的系统和用户权限信息，我们改密码和新增用户，实际上就是对这个库进行操作。
2、显示库中的数据表：
use mysql;
show tables;
3、显示数据表的结构：
describe 表名;
4、建库与删库：
create database 库名;
drop database 库名;
5、建表：
use 库名;
create table 表名(字段列表);
drop table 表名;
6、清空表中记录：
delete from 表名;
7、显示表中的记录：
select * from 表名;

第五招、导出和导入数据
1. 导出数据：
mysqldump --opt test > mysql.test
即将数据库test数据库导出到mysql.test文件，后者是一个文本文件
如：mysqldump -u root -p123456 --databases dbname > mysql.dbname
就是把数据库dbname导出到文件mysql.dbname中。
2. 导入数据:
mysqlimport -u root -p123456 < mysql.dbname。
不用解释了吧。
3. 将文本数据导入数据库:
文本数据的字段数据之间用tab键隔开。
use test;
load data local infile "文件名" into table 表名;

MySQL 包括一个服务器进程管理数据库，以及一系列访问数据库和创建应用的工具：

mysql               : 在 MySQL 中执行 SQL 查询，也可以执行在文件中存储的SQL命令；
mysqlaccess : 管理用户；
mysqladmin   : 管理数据库服务器，包括数据库的创建和移除；
mysqld            : 实际的 MySQL 服务器进程；
mysqldump    : 将数据库或表的定义和内容转储到文件；
mysqlhotcopy : 热备份；
mysqlimport   : 将不同文件格式的数据导入到 MySQL 表中；
mysqlshow    : 显示服务器或者任何对象（数据库和表）的信息。

mysql_secure_installation : 用于管理 root 密码，远程访问、移除临时（测试）数据库及临时用户的一个脚本。

一般来讲，Root 应只用于数据库本机上登录 MySQL，我们可以增加一个拥有超级管理权限的用户 'admin' 来实现远程的维护。

Tips:

1、用 root 登录；(在命令行键入：mysql -u用户名 -p密码)
2、执行如下语句：
mysql>grant all privilages on *.* to admin@localhost identified by 'password' with grant option;
mysql>grant all privilages on *.* to admin@"%" identified by 'password' with grant option;

"%"是通配符，授予 admin 用户可以从任何主机发起访问，password 是为 admin 用户设置的密码。

＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝＝

mysql命令行常用命令

第六招、执行外部脚本文件

mysql - u test - p1234 --database BugFree < D:/GreenAMP/BugFree.sql

discuz数据表优化

gouki — 2009-06-22 21:09

这是来自imysql.cn的文章，作者是叶金荣，第一部分内容是3年前的了。可略作参考，估计7.0的数据库应该已经部分解决这个问题，第二部分是最新的。或许也能帮助你解决一些问题。

对于我来说是不用的啦。。我的论坛才几十个人。根本不需要用到这些功能。哇哈哈哈。
不过，我记得，如果是自己的服务器架设的论坛，DZ可以通过打开APC来进行缓存加速（好象是6.X版本中的功能。7.X没有研究过是不是还存在）

不说废话，看叶金荣先生的文章：

第一部分：

一. 前言
近日由于需要,对discuz论坛(简称dz)进行优化,当然了,只是涉及到数据库的优化.
先说一下服务器及dz的数据量,2 * Intel(R) Xeon(TM) CPU 2.40GHz, 4GB mem, SCISC硬盘.
MySQL 版本为 4.0.23. 数据表情况:
cdb_attachments 2万
cdb_members 10万
cdb_posts 68万
cdb_threads 7万
二. 缓存优化
在 my.cnf 中添加/修改以下选项:

#取消文件系统的外部锁
skip-locking
#不进行域名反解析,注意由此带来的权限/授权问题
skip-name-resolve
#索引缓存,根据内存大小而定,如果是独立的db服务器,可以设置高达80%的内存总量
key_buffer = 512M
#连接排队列表总数
back_log = 200
max_allowed_packet = 2M
#打开表缓存总数,可以避免频繁的打开数据表产生的开销
table_cache = 512
#每个线程排序所需的缓冲
sort_buffer_size = 4M
#每个线程读取索引所需的缓冲
read_buffer_size = 4M
#MyISAM表发生变化时重新排序所需的缓冲
myisam_sort_buffer_size = 64M
#缓存可重用的线程数
thread_cache = 128
#查询结果缓存
query_cache_size = 128M
#设置超时时间,能避免长连接
set-variable = wait_timeout=60
#最大并发线程数,cpu数量*2
thread_concurrency = 4
#记录慢查询,然后对慢查询一一优化
log-slow-queries = slow.log
long_query_time = 1
#关闭不需要的表类型,如果你需要,就不要加上这个
skip-bdb

以上参数根据各自服务器的配置差异进行调整,仅作为参考.
三. 索引优化
上面提到了,已经开启了慢查询,那么接下来就要对慢查询进行逐个优化了.
1. 搜索优化
搜索的查询SQL大致如下:

SELECT t.* FROM cdb_posts p, cdb_threads t WHERE
t.fid IN ('37', '45', '4', '6', '17', '41', '28', '32', '31', '1', '42')
AND p.tid=t.tid AND p.author LIKE 'JoansWin'
GROUP BY t.tid ORDER BY lastpost DESC LIMIT 0, 80;

用 EXPLAIN 分析的结果如下:

mysql>EXPLAIN  SELECT t.* FROM cdb_posts p, cdb_threads t WHERE
t.fid IN ('37', '45', '4', '6', '17', '41', '28', '32', '31', '1', '42')
AND p.tid=t.tid AND p.author LIKE 'JoansWin'
GROUP BY t.tid ORDER BY lastpost DESC LIMIT 0, 80; 
+-----------+------------+----------+--------------+-------------+-----------+-------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref         | rows  | Extra
+-----------+------------+----------+--------------+-------------+-----------+-------------+
|  1 | SIMPLE      | t     | range | PRIMARY,fid   | fid  | 2       | NULL        | 66160 | Using where; 
Using temporary; Using filesort |
|  1 | SIMPLE      | p     | ref   | tid           | tid  | 3       | Forum.t.tid   |    10 | Using where
| +----+-------------+-------+-------+---------------+------+---------+-------------+-------+
---------

只用到了 t.fid 和 p.tid,而 p.author 则没有索引可用,总共需要扫描
66160*10 = 661600 次索引,够夸张吧 :(
再分析 cdb_threads 和 cdb_posts 的索引情况:

mysql>show index from cdb_posts; 
+-----------+------------+----------+--------------+-------------+-----------+----------
---+----------+--------+------+--+
| Table     | Non_unique | Key_name | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | 
Packed | Null | Index_type | Comment | +-----------+------------+----------+--------------+----
---------+-----------+-------------+----------+--------+------+--+
| cdb_posts |          0 | PRIMARY  |            1 | pid         | A         |      680114 |     NULL | NULL   |
| BTREE      |         |
| cdb_posts |          1 | fid      |            1 | fid         | A         |          10 |     NULL | NULL   |
| BTREE      |         |
| cdb_posts |          1 | tid      |            1 | tid         | A         |       68011 |     NULL | NULL   |
| BTREE      |         |
| cdb_posts |          1 | tid      |            2 | dateline    | A         |      680114 |     NULL | NULL   |
| BTREE      |         |
| cdb_posts |          1 | dateline |            1 | dateline    | A         |      680114 |     NULL | NULL   |
| BTREE      |         | 
+-----------+------------+----------+--------------+-------------+-----------+---

以及

mysql>show index from cdb_threads; 
+-----------+------------+----------+--------------+-------------+-----------+-------------+
----------+--------+------+-----+
| Table       | Non_unique | Key_name  | Seq_in_index | Column_name | Collation | Cardinality | Sub_part |
Packed | Null | Index_type | Comment | +-----------+------------+----------+--------------+-----
--------+-----------+-------------+----------+--------+------+-----+
| cdb_threads |          0 | PRIMARY   |            1 | tid         | A         |       68480 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | lastpost  |            1 | topped      | A         |           4 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | lastpost  |            2 | lastpost    | A         |       68480 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | lastpost  |            3 | fid         | A         |       68480 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | replies   |            1 | replies     | A         |         233 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | dateline  |            1 | dateline    | A         |       68480 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | fid       |            1 | fid         | A         |          10 |     NULL | NULL   |
| BTREE      |         |
| cdb_threads |          1 | enablehot |            1 | enablehot   | A         |           2 |     NULL | NULL   |
| BTREE      |         | +-------------+------------+-----------+--------------+-------------+------

看到索引 fid 和 enablehot 基数太小,看来该索引完全没必要,不过,对于fid基数较大的情况,则可能需要保留>该索引.
所做修改如下:

ALTER TABLE `cdb_threads` DROP INDEX `enablehot`, DROP INDEX `fid`, ADD INDEX (`fid`, `lastpost`);
ALTER TABLE `cdb_posts` DROP INDEX `fid`, ADD INDEX (`author`(10));
OPTIMIZE TABLE `cdb_posts`;
OPTIMIZE TABLE `cdb_threads`;

在这里, p.author 字段我设定的部分索引长度是 10, 是我经过分析后得出来的结果,不同的系统,这里的长度也不同,最好自己先取一下平均值,然后再适当调整.
现在,再来执行一次上面的慢查询,发现时间已经从 6s 变成 0.19s,提高了 30 倍.
这次先到这里,下次继续 ^_^

第二部分：

很早以前写过一个文章，是关于discuz论坛的优化：MySQL优化之 Discuz论坛优化。写的时候是2006年，没想到过了这么久，discuz论坛的问题还是困扰着很多网友，其实从各论坛里看到的问题总结出来，很关键的一点都是因为没有将数据表引擎转成InnoDB导致的，discuz在并发稍微高一点的环境下就表现的非常糟糕，产生大量的锁等待，这时候如果把数据表引擎改成InnoDB的话，我相信会好很多。这次就写个扫盲贴吧。

1. 启用innodb引擎，并配置相关参数

#skip-innodb
innodb_additional_mem_pool_size = 16M #一般16M也够了，可以适当调整下
innodb_buffer_pool_size = 6G #如果是专用db的话，一般是内存总量的80%
innodb_data_file_path = ibdata1:1024M:autoextend
innodb_file_io_threads = 4
innodb_thread_concurrency = 20
innodb_flush_log_at_trx_commit = 1
innodb_log_buffer_size = 16M
innodb_log_file_size = 256M
innodb_log_files_in_group = 3
innodb_max_dirty_pages_pct = 50
innodb_lock_wait_timeout = 120
innodb_file_per_table

2. 修改表引擎为innodb

mysql> alter table cdb_access engine = innodb;

其他表类似上面，把表名换一下即可...
将表存储引擎改成innodb后，不仅可以避免大量的锁等待，还可以提升查询的效率，因为innodb会把data和index都放在buffer pool中，效率更高。

膘叔认为：如果有自己的服务器，可以考虑做几件事情
1、如果有APC功能打开APC
2、如果没有APC，可以考虑把缓存目录指定为内存看看
3、GZIP关闭，少用rewrite等
4、在大负载的情况下，又只有一台服务器，考虑改程序，延迟插入或者其他的。。。（不太现实，哈哈）

关于mysql 1366的错误。

gouki — 2009-06-22 15:05

在查mysql 1366的错误原因时，发现一些有趣的回答。地址为：http://zhidao.baidu.com/question/59029575.html

不过，还是有人给出了比较好的解决方法：

http://www.phplamp.org/2008/11/mysql-1366-problem-solution/

MySQL 1366错误大致描述如下
1. SQL Error: 1366: Incorrect string value: "\xE8\xAF\xA6\xE7\xBB\x86…" for column "address" at row 1
解决办法：检查数据库此字段的字符集与整理字符集是否与SQL语句传递数据的字符集相同；不相同则会引发MySQL1366错误。
修改MySQL该字段的字符集与整理规则即可。假设数据表为phplamp, SQL语句的字符集为utf8，出错的字段为address：
MySQL 1366 错误解决办法
1. #检查数据表所有字段的状态
2. ->show full columns from phplamp;
3. #发现address字段的Collation项非utf8，修改它！
4. ->alter table phplamp change name name varchar(100) character set utf8 collate utf8_unicode_ci not null default '';
修改完字段的字符集后可以再使用show full columns from table_name命令检查一下，以确保万无一失。假如您的SQL字符集为GBK或是GB2312或是其它的话，只需要将数据表字段的字符集更改为其相应的编码即可。
再送上一个MySQL的命令：
修改数据表的字符集与整理
1. ->show full columns from table_name;

mssql和mysql区别

gouki — 2009-05-26 22:49

偶尔看到这篇文章，觉得转下来也挺不错。毕竟现在mssql用的人也挺多，不是吗？
数据库迁移问题也可以多注意一下。。

原文地址：
内容如下：http://www.cnblogs.com/perfectdesign/archive/2009/05/22/mssql2mysql.html

最近在做mssql转换成mysql的工作，总结了点经验，跟大家分享一下。

同时这些也会在不断更新。也希望大家补充。

1 mysql支持enum,和set类型，sql server不支持

2 mysql不支持nchar,nvarchar,ntext类型

3 mysql的递增语句是AUTO_INCREMENT，而mssql是identity(1,1)

4 msms默认到处表创建语句的默认值表示是((0)),而在mysql里面是不允许带两括号的

5 mysql需要为表指定存储类型

6 mssql识别符是[],[type]表示他区别于关键字，但是mysql却是 `，也就是按键1左边的那个符号

7 mssql支持getdate()方法获取当前时间日期，但是mysql里面可以分日期类型和时间类型，获取当前日期是cur_date()，当前完整时间是 now()函数

8 mssql不支持replace into 语句，但是在最新的sql20008里面，也支持merge语法

9 mysql支持insert into table1 set t1 = ‘’, t2 = ‘’ ,但是mssql不支持这样写

10 mysql支持insert into tabl1 values (1,1), (1,1), (1,1), (1,1), (1,1), (1,1), (1,1)

11 mssql不支持limit语句，是非常遗憾的，只能用top 取代limt 0,N，row_number() over()函数取代limit N,M

12 mysql在创建表时要为每个表指定一个存储引擎类型，而mssql只支持一种存储引擎

13 mysql不支持默认值为当前时间的datetime类型（mssql很容易做到），在mysql里面是用timestamp类型

14 mssql里面检查是否有这个表再删除，需要这样：

if exists (select * from dbo.sysobjects where id = object_id(N'uc_newpm') and OBJECTPROPERTY(id, N'IsUserTable') = 1)

但是在mysql里面只需要 DROP TABLE IF EXISTS cdb_forums;

15 mysql支持无符号型的整数，那么比不支持无符号型的mssql就能多出一倍的最大数存储

16 mysql不支持在mssql里面使用非常方便的varchar(max)类型，这个类型在mssql里面既可做一般数据存储，也可以做blob数据存储

17 mysql创建非聚集索引只需要在创建表的时候指定为key就行，比如：KEY displayorder (fid,displayorder) 在mssql里面必须要：create unique nonclustered index index_uc_protectedmembers_username_appid on dbo.uc_protectedmembers

(username asc,appid asc)

18 mysql text字段类型不允许有默认值

19mysql的一个表的总共字段长度不超过65XXX。

20一个很表面的区别就是mysql的安装特别简单，而且文件大小才110M（非安装版），相比微软这个庞然大物，安装进度来说简直就是.....

21mysql的管理工具有几个比较好的，mysql_front,和官方那个套件，不过都没有SSMS的使用方便，这是mysql很大的一个缺点。

22mysql的存储过程只是出现在最新的版本中，稳定性和性能可能不如mssql。

23 同样的负载压力，mysql要消耗更少的CPU和内存，mssql的确是很耗资源。

24php连接mysql和mssql的方式都差不多，只需要将函数的mysql替换成mssql即可。

25mysql支持date,time,year类型，mssql到2008才支持date和time。