MySQL易学易用，且附带丰富的技术文档，这二个因素使之被广泛应用。然而，随着MySQL发展之迅速，即使一个MySQL老手有时也会为该软件出其不意的功能感叹。本文将为你介绍这些不为人知的特性。

以XML格式查看查询结果

通过使用传统—xml 选项调用MySQL命令行客户程序，你可以以XML格式(而不是传统的列表形式)来查看MySQL查询结果。如果你打算将查询输出与其它程序集成在一起，这一技巧非常有用，这里是一个例子：

表A

shell> mysql --xml

mysql> SELECT * FROM test.stories;
<?xml version="1.0"?>

<resultset statement="SELECT * FROM test.stories">
<row>
<id>1</id>
<headline>This is a test</headline>
<tstamp>2005-07-28 00:14:57</tstamp>
</row>

<row>
<id>2</id>
<headline>This is the second test</headline>
<tstamp>2005-07-28 00:15:11</tstamp>
</row>
</resultset>
2 rows in set (0.11 sec)

快速重建索引

通常情况下，如果你想改变服务器的全文搜索变量，你需要在表格中重新建立全文索引，以确保你的更新得到映射。这一操作将会花费大量的时间，特别是如果你需要处理很多数据的时候。一种快速的解决方法是使用REPAIR TABLE命令，以下为演示过程：

表B

mysql> REPAIR TABLE content QUICK;
+-----------+--------+----------+----------+
| Table| Op| Msg_type | Msg_text |
+-----------+--------+----------+----------+
| content| repair | status| OK|
+-----------+--------+----------+----------+
1 row in set (0.05 sec)

压缩一定的表格类型

如果你处理的是只读MyISAM表格，MySQL允许你将其压缩以节省磁盘空间。对此可以使用包括myisampack，如下所示：

表C

shell> myisampackmovies.MYI
Compressing movies.MYD: (146 records)
- Calculating statistics
- Compressing file
41.05%

使用传统SQL

MySQL支持SQL查询中的传统用法，支持IF与CASE结构。以下是一个简单的例子：

表D

mysql> SELECT IF (priv=1, 'admin', 'guest') As usertype FROM privs WHERE username = 'joe';
+----------+
| usertype |
+----------+
| admin|
+----------+
1 row in set (0.00 sec)

大部分服务器管理员知道MySQL数据库管理系统（RDBMS）是高度灵活的软件块，带有范围广阔的启动选项，可以用来修改相关行为。然而，大部分人却不清楚，标准MySQL客户端带有同等大量的启动选项，其中一些在日常MySQL交互作用中极为有用。这些选项本身不是 “秘密”，而它们中很多未被使用，甚至其中一些可以显著利于服务器交互作用的过程处理。

表A是其中一些不太知名的MySQL客户程序启动选项。表格中的每一条目解释了每个选项的功能以及用法。这将给予你MySQL应用范围和深度等问题一些想法，帮助你完成日常应用程序开发。

表 A

选项  

功能  

何时使用

压缩  

本选项压缩了客户和服务器之间的上游和下游数据包传送，假设连接的两端支持该压缩。  

使用本选项提高了通讯宽带被限制时的性能—例如，通过一个慢网连接

调试  

该选项强制MySQL写调试数据到一个指定的日志文件，包括启动和关闭以及过程处理。可以结合--debug-info的其他调试信息选项使用  

当处理有经验的服务器或客户时，使用本选项获得MySQL的详细诊断信息。

强制  

本选项强制MySQL继续处理SQL命令，甚至当错误发生时。  

在自动化安装/解安装程序中使用本选项—例如，当你尝试将大批量注入记录加入数据库，作为程序安装的一部分，并且不想复制条目来中断过程

呼机  

本选项导出MySQL的查询输出，至一个外部“pager”程序，例如cat，少或多  

当你的查询返回一个大的结果设置时使用本选项，并且你希望通过屏幕交互式翻页

xml  

本选项格式化你的MySQL查询结果，作为良好格式化的XML  

当你希望将查询以标准格式输出包时，通常作为与第三方程序结合的前奏

单-数据库  

除了与数据库命名相关的选项以外，本选项告诉MySQL客户忽略所有命令  

使用本选项泄漏来自SQL注入文件的有关单数据库的行动，或者跳过某数据库更新。

字母T  

本选项让你将所有查询输出日志记入一个外部文件  

、

使用本选项当你需要一个事务处理记录时，或者用于以后参考，或用于保留查帐索引

--wait

等待  

通常，如果无法连接到服务器，MySQL客户自动进行异常中断。本选项强制它等待定义的时间间隔，然后重试。  

Use this option to cut down on keystrokes when attempting to contact a remote or non-responsive MySQL server.

当尝试连接一个远程或未响应MySQL服务器时，使用本选项切断按键 

安全更新  

本选项告诉MySQL忽视所有无资格DML命令——即该命令不包含过滤标准，例如WHERE, LIMIT or HAVING子句。这提供了防止意外修改或删除整个表格或数据库的安全网络。  

当你向自动保护自己防止危险查询时使用本选项，这些查询可能引起分布广泛的数据损坏或丢失

--prompt

提示  

本选项允许你改变标准mysql>命令提示，使用各种未定义格式。 

使用本选项将使你的MySQL打印有用的导航或暂时信息——例如，目前日期或时间，服务器统计和泥在数据库/列表层次的位置

你可以在MySQL用户指南中阅读更多相关（及其他选项）内容。

　　MySQL易学易用，附带丰富的技术文档，这两个因素使之被广泛应用。然而，随着MySQL发展加快，即使一个MySQL老手有时也会为该软件出其不意的功能感叹。本文将为你介绍这些不为人知的特性。

　　以XML格式查看查询结果

　　通过使用传统—xml 选项调用MySQL命令行客户程序，你可以以XML格式(而不是传统的列表形式)来查看。

　　MySQL查询结果

　　如果你打算将查询输出与其它程序集成在一起，这一技巧非常有用，这里是一个例子：

表A

shell> mysql --xml
mysql> SELECT * FROM test.stories;
1
This is a test
2
This is the second test
2rows in set (0.11 sec)

　　快速重建索引

　　通常情况下，如果你想改变服务器的全文搜索变量，你需要在表格中重新建立全文索引，以确保你的更新得到映射。这一操作将会花费大量的时间，特别是如果你需要处理很多数据的时候。一种快速的解决。

　　方法是使用REPAIR TABLE命令，以下为演示过程：

表B

mysql> REPAIR TABLE content QUICK;
+-----------+--------+----------+----------+
| Table| Op| Msg_type | Msg_text |
+-----------+--------+----------+----------+
| content| repair | status| OK|
+-----------+--------+----------+----------+
1 row in set (0.05 sec)

　　压缩一定的表格类型

　　如果你处理的是只读MyISAM表格，MySQL允许你将其压缩以节省磁盘空间。对此可以使用包括myisampack，如下所示：

表C

shell> myisampackmovies.MYI
Compressing movies.MYD: (146 records)
- Calculating statistics
- Compressing file
41.05%

　　使用传统SQL

　　MySQL支持SQL查询中的传统用法，支持IF与CASE结构。以下是一个简单的例子：

表D

mysql> SELECT IF (priv=1, 'admin', 'guest')
As usertype FROM privs WHERE username = 'joe';
+----------+
| usertype |
+----------+
| admin|
+----------+
1 row in set (0.00 sec)

　　以CSV格式输出表格数据

　 　MySQL 输出文件包含一个全部SQL命令列表。如果你想将输出文件导入到MySQL，这一功能非常实用，但如果目标程序(比如Excel)不能与SQL相互通讯， 这一方法将行不通。在这种情况下，可以通过告诉MySQL ，以CSV格式建立输出文件，这种CSV格式很方便地导入到绝大部分的程序。这里演示了 mysqldump的操作过程：

shell> mysqldump -T .
 --fields-terminated-by=", " mydbmytable

　　这将在当前目录中生成一个文本文件，包含来自mydb.mytable列表中以逗号为间隔符的记录。

mysql 4.1的改变造成的乱码解决方法

第一个方法：

MySQL 4.1 中文乱码的问题

最近要将 MySQL 4.0 升级到 MySQL 4.1 ，发现了中文乱码的问题，希望以下见解对大家有用。

1. MySQL 4.1 在文字上有很大改进，它有了 Character Set 与 Collation 的慨念。

2. 在 MySQL 4.0 ，一般的程式都会将文字以拉丁文 ( latin)  来储存，就算我们输入中文字，结果仍是放在以拉丁文设置的文字栏里头，这对 MySQL 4.0 与以 MySQL 4.0 为基楚的程式来说，并不会有问题。

3. 可是 MySQL 4.1 的系统编码是预设用 UTF-8 的，当要 restore MySQL 4.0 的 backup 档到 MySQL 4.1 时，乱码就出现了。原因在于 MySQL 4.1 将 latin 码转换过来，而后转换是并不完全完美的，这导致了出现少量文字出现乱码现象。

解决PHP存取MySQL 4.1乱码问题

QUOTE:
从MySQL 4.1开始引入的多语言支持确实很棒，而且一些特性已经超过了其他的数据库系统。不过我在测试过程中发现使用适用于MySQL 4.1之前的PHP语句操作MySQL数据库会造成乱码，即使是设置过了表字符集也是如此。我读了一下新的MySQL在线手册中第十章 "Character Set Support"后终于找到了解决方法并测试通过。

MySQL 4.1的字符集支持(Character Set Support)有两个方面：字符集(Character set)和排序方式(Collation)。对于字符集的支持细化到四个层次: 服务器(server)，数据库(database)，数据表(table)和连接(connection)。

查看系统的字符集和排序方式的设定可以通过下面的两条命令：

CODE:

mysql> SHOW VARIABLES LIKE 'character_set_%';

  +--------------------------+----------------------------+
  | Variable_name | Value |
  +--------------------------+----------------------------+
  | character_set_client | latin1 |
  | character_set_connection | latin1 |
  | character_set_database | latin1 |
  | character_set_results | latin1 |
  | character_set_server | latin1 |
  | character_set_system | utf8 |
  | character_sets_dir | /usr/share/mysql/charsets/ |
  +--------------------------+----------------------------+
  7 rows in set (0.00 sec)

  mysql> SHOW VARIABLES LIKE 'collation_%';
  +----------------------+-------------------+
  | Variable_name | Value |
  +----------------------+-------------------+
  | collation_connection | latin1_swedish_ci |
  | collation_database | latin1_swedish_ci |
  | collation_server | latin1_swedish_ci |
  +----------------------+-------------------+
  3 rows in set (0.00 sec)

上面列出的值就是系统的默认值。如果你奇怪系统怎么默认是latin1的瑞典语排序方式,原因是MySQL由瑞典的T.c.X.DataKonsultAB公司(目前公司名称为MySQL AB)开发，不用再多说了吧。
当我们按照原来的方式通过PHP存取MySQL数据库时，就算设置了表的默认字符集为utf8并且通过UTF-8编码发送查询，你会发现存入数据库的仍然是乱码。问题就出在这个connection连接层上。解决方法是在发送查询前执行一下下面这句：

SET NAMES 'utf8';

它相当于下面的三句指令：

CODE:

SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = utf8;
再试试看，正常了吧？

就是连接之后加个查询

CODE:

$this->query(”SET NAMES ‘utf8＇”);
看了手册第10章觉得主要还是Character Sets的问题。
character_set_client， character_set_results，character_set_connection三个运行变量是造成乱码的关键。mysql把客户端提交 的查询由character_set_client转换为character_set_connection
，由于默认网页提交的查询是 gb2312(表单页面meta里可以看到)，而mysql默认将其当作utf8（可以查到此时的 character_set_client＝utf8），所以必然乱码。同理，mysql返回的结果是已经转换成 character_set_results编码的（与表的编码无关），同样默认是utf8，而网页页面把它当gb2312处理，所以必然有标题等由数据 库读出的字段是乱码而其他部门文字不乱码的现象。
以上这个例子是utf8字符集，用此方法，设置为gbk，即可解决

第三个方法：

mysql 4.1乱码终极解决方案

请注意，本文只针对mysql 4.1，其它版本的mysql请看别的文章。
mysql4.1是比较烦人，支持多语言的细化设置，再加上phpmyadmin2.6也比较笨，默认就是改不动的utf8，怎么弄都乱码。
好了，废话少说，我们来一步步解决这个问题：
1.修改/etc/my.cnf文件，改成这样：
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
default-character-set=utf8

[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

注意：就是加入了一句default-character-set=utf8。

2./etc/init.d/mysqld restart 重新启动mysql；
3.打开phpmyadmin，选择lang为"Chines simplifies(zh-utf-8)",选择"MySQL 连接校对"为"utf8_general_ci "点“显示 MySQL 的运行信息”--“变量”，可以看到：
character set client utf8 utf8
character set connection utf8 utf8
character set database utf8 utf8
character set results utf8 utf8
character set server utf8 utf8
character set system utf8 utf8
collation connection utf8_general_ci utf8_general_ci
collation database utf8_general_ci utf8_general_ci
collation server utf8_general_ci utf8_general_ci
从这里可以看到character全部变成utf8了。
有人要问，为什么都要改成utf8呢？改成GB2312不行吗？
解释如下：
我也不想改成utf8，只是phpmyadmin2.6在mysql4.1的时候只会用utf8，连其他页面的charset也都是utf8，改成gb2312一定会乱码，我们只能凑phpmyadmin了。
只有在mysql3.23的时候，phpmyadmin才会多一个gb2312的页面charset，这时候是正常的。
3.将以前的mysql3的库文件导入mysql4.1的库
有两种情况：
一是从phpmyadmin上导入，这时候你要注意的是在选择库文件的页面左下脚有个“文件的字符集：”，默认是utf8，要改成gb2312，否则导进去乱码；
二是在linux下导入，这时候你需要先在库文件的头部加一行:
SET NAMES 'gb2312'; 注意最后也是;号，别漏了。
然后执行mysql -u用户名 -p密码 xxx.sql > 库名
导入完成以后再用phpmyadmin打开看，里面的中文字就是正确的。
4.从mysql4.1里导出库文件
一.用phpmyadmin导出
导出倒是问题不大，如果phpmyadmin的浏览页面里显示的中文是正常的，那么导出肯定也是正常的
二.在linux上导出
如果用mysqldump导出出现了乱码也没有关系，可以运行iconv来转换一下
iconv -c -f UTF-8 -t GB2312 库文件名 > 新的gb2312的库文件名

综上所述，你要注意：
1。尽量在需要导入的库文件的开头加入SET NAMES 'gb2312';告诉mysql你要导入的是一个gb2312的文件；
2。可能你需要这个：
SET NAMES 'utf8';
在登陆到mysql后用，把character的一些默认参数改到utf8上，有时可以减少一些困扰，不过也不是必须的。
在mysql上使用:
SHOW VARIABLES LIKE 'character_set_%';
用来查看当前的状态。
3.如果出现乱码也不要怕，一是你要注意留存原有的备份，二是用iconv来进行转化。
在正常使用之前注意做导入导出的测试，确保万无一失。

下面再说明一下,网上很多朋友说Mysql4.1的只能升,不能降. 这是不正确的. 同样使用mysqldump 导出数据库时加一个 --compatible 的参数.也千万不能忘了--default-character-set=这个设定字符集的参数.
示范: mysqldump -uroot -pPassword --compatible=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql
ok 这样导出来的文件,就可以在Mysql4.0.X和Mysql.3.2.X版本中使用了. 

Linux下 Mysql 5 中文乱码的彻底解决及应用的一些注意事项

一. 自从mysql4.1开始，mysql对中文的支持问题是比较烦人的，怎么弄都乱码，如今mysql5 据说是mysql的新纪元，但从官方下载安装的mysql5仍存在乱码现象，这里就是针对此现象做的讨论：

建 议最好是下载mysql的源码进行编译，这是由于官方编译的mysql的默认支持编码是latin字符集，所以中文字符在数据库里查看的时候看到的是乱 码。编译MySQL时使用withcharset=编码，可以方便地把mysql编译成该编码形式，这样MySQL就会直接支持中文查找和排序，-- with-extra-charsets参数指定其它可用的字符集。

下载并解压源码包，打开INSTALL-SOURCE，这里介绍了linux下详细的安装方法，所以大家所要注意的只是下面的configure指令：
groupadd mysql
useradd -g mysql mysql
./configure --with-charset=gbk --with-collation=gbk_chinese_ci --with-extra-charsets=gb2312,big5,utf8,binary,ascii --prefix=/usr/local/mysql
make
make install
cp support-files/my-medium.cnf /etc/my.cnf
cd /usr/local/mysql
bin/mysql_install_db --user=mysql
chown -R root .
chown -R mysql var
chgrp -R mysql .
bin/mysqld_safe --user=mysql &
bin/mysql
mysql> show variables;

你可以看到全局的字符集参数全是gbk，gb2312字集应该包含在gbk里，所以不讨论。

进行和平常mysql4.0一样的php操作，你会发现仍然出现中文乱码现象。

这里要说明的是：从mysql 4.1开始，必需在mysql数据库连接后对应用的字符集做出说明，否则非英文字母的文字存取都无法解释变成?号。

解决方法就是要适应新版mysql的要求：

在连接mysql数据库后执行set character set 字符集，该指令在最新版的mysql 5如果默认字集和存储相符可以免设：

set character set gbk;

在php里应该是这么写:mysql_query("set character set gbk");

指令大小写均可

phpwind和discuz是广泛应用的国产php论坛，大量的朋友在应用它，了解了以上步骤，你也可以对论坛源码进行很小的修改，安全地把数据库升级到mysql5：

找到include/db_mysql.php，修改function connect(...){.....}
在选择数据库mysql_select_db($dbname);后面加上一句mysql_query('set character set gbk');存盘。

二. 文件的导入导出：如果存入非gbk字符，这时候你需要先在导入文件的头部加一行: SET NAMES '字符集'; 并注意最后也是;号，别漏了。

文件导入和导出执行

mysql -u用户名 -p密码 数据库名

mysqldump -u用户名 -p密码 数据库名>data.sql

如果用mysqldump导出数据出现了乱码也没有关系，可以运行iconv来转换一下：

iconv -c -f utf8 -t gbk 库文件名>新的gbk的库文件名

综上所述，你要注意：

1。尽量在需要导入的库文件的开头加入set names 'gbk';告诉mysql你要导入的是一个gbk的文件；

2。在mysql上使用 show variables;或show variables like 'character_set_%'; 用来查看当前的字集状态。

3。如果出现乱码也不要怕，其一是你要注意留存原有的备份，其二是用iconv来进行转化。

#PHP连接问题：

由于MySQL 4.1版本开始密码的hash算法改变，所以连接数据库时可能会出现Client does not support authentication protocol问题

此问题在mysql 5中不存在，mysql 5不需要以下的设置。

可以通过一下两种方法解决数据库用户密码不符问题：

其一: mysql> SET PASSWORD FOR 'some_user'@'some_host' = OLD_PASSWORD('newpwd');

其二: mysql> Update mysql.user SET Password = OLD_PASSWORD('newpwd') Where Host = 'some_host' AND User = 'some_user'

PHP输出的其它乱码问题：

如果将mysql编译为默认编码gbk的话，又会造成非gbk数据直接导入显示为乱码，比如部份utf8存储的字符，如果你大部份数据是utf8字集，当然得把mysql编译为默认编码utf8才合适。

Mysql 4.1.x出来以后，引入了collation (校勘)的概念，终于有办法让mysql同时支持多种编码的数据库了，所以PHP要用以下SQL语句来创建utf-8编码的数据库：
Create DATABASE `mytest` DEFAULT CHARACTER SET utf8 COLLATE utf8_general_ci;

但是仅仅是将数据库的校勘改为utf-8是不够的，还必须在连接了mysql数据库之后用这个语句来设置：set names 'utf8';才能在php程序里得到正确编码的字符，并将其显示在web页面里。

mysql_query("set names 'utf8'",$connection);

下面再说明一下,网上很多朋友说Mysql4.1的只能升,不能降. 这是不正确的. 同样使用mysqldump 导出数据库时加一个 --compatible 的参数.也千万不能忘了--default-character-set=这个设定字符集的参数。

示范: mysqldump -uroot -pPassword --compatible=mysql40 --default-character-set=gb2312 discuz>d:discuz.sql

ok 这样导出来的文件,就可以在Mysql4.0.X和Mysql.3.2.X版本中使用了.

下面要写的是一篇非常无聊的东西，充斥了大量各式各样的编码、转换、客户端、服务器端、连接……呃，我自己都不愿意去看它，但想一想，写下来还是有点意义的，原因有四：

MySQL 4.1 对多语言的支持有了很大变化 (这导致了问题的出现)；
尽管大部分的地方 (包括个人使用和主机提供商)，MySQL 3 仍然占主导地位；但 MySQL 4.1 是 MySQL 官方推荐的数据库，已经有主机提供商开始提供并将会越来越多；
许多 PHP 程序以 MySQL 作为默认的数据库管理软件，但它们一般不区分 MySQL 4.1 与 4.1 以下版本的区别，笼统地称“MySQL 3.xx.xx 以上版本”就满足安装需求了；
因为 latin1 在许多地方 (下边会详细描述具体是哪些地方) 作为默认的字符集，成功的蒙蔽了许多 PHP 程序的开发者和用户，掩盖了在中文等语言环境下会出现的问题；
简单的说，MySQL 自身的变化和使用 MySQL 的 PHP 程序对此忽略，导致了问题的出现和复杂化，而由于大部分用户使用的是英文，使这种问题不被重视。这里提到的 PHP 程序，主要就 WordPress 而言。

MySQL 4.1 字符集支持的原理MySQL 4.1 对于字符集的指定可以细化到一台机器上安装的 MySQL，其中的一个数据库，其中的一张表，其中的一栏，应该用什么字符集。但是，传统的 Web 程序在创建数据库和数据表时并没有使用那么复杂的配置，它们用的是默认的配置，那么，默认的配置从何而来呢？

编译 MySQL 时，指定了一个默认的字符集，这个字符集是 latin1；
安装 MySQL 时，可以在配置文件 (my.ini) 中指定一个默认的的字符集，如果没指定，这个值继承自编译时指定的；
启动 mysqld 时，可以在命令行参数中指定一个默认的的字符集，如果没指定，这个值继承自配置文件中的；
此时 character_set_server 被设定为这个默认的字符集；
当创建一个新的数据库时，除非明确指定，这个数据库的字符集被缺省设定为 character_set_server；
当选定了一个数据库时，character_set_database 被设定为这个数据库默认的字符集；
在这个数据库里创建一张表时，表默认的字符集被设定为 character_set_database，也就是这个数据库默认的字符集；
当在表内设置一栏时，除非明确指定，否则此栏缺省的字符集就是表默认的字符集；
这个字符集就是数据库中实际存储数据采用的字符集，mysqldump 出来的内容就是这个字符集下的；
简 单的总结一下，如果什么地方都不修改，那么所有的数据库的所有表的所有栏位的都用 latin1 存储，不过我们如果安装 MySQL，一般都会选择多语言支持，也就是说，安装程序会自动在配置文件中把 default_character_set 设置为 UTF-8，这保证了缺省情况下，所有的数据库的所有表的所有栏位的都用 UTF-8 存储。

当一个 PHP 程序与 MySQL 建立连接后，这个程序发送给 MySQL 的数据采用的是什么字符集？MySQL 无从得知 (它最多只能猜测)，所以 MySQL 4.1 要求客户端必须指定这个字符集，也就是 character_set_client，MySQL 的怪异之处在于，得到的这个字符集并不立即转换为存储在数据库中的那个字符集，而是先转换为 character_set_connection 变量指定的一个字符集；这个 connection 层究竟有什么用我不大明白，但转换为 character_set_connection 的这个字符集之后，还要转换为数据库默认的字符集，也就是说要经过两次转换；当这个数据被输出时，又要由数据库默认的字符集转换为 character_set_results 指定的字符集。

一个典型的环境典型的环境以我自己的电脑上安装的 MySQL 4.1 为例，我自己的电脑上安装着 Apache 2，PHP 5 和 WordPress 1.5.1.3，MySQL 配置文件中指定了 default_character_set 为 utf8。于是问题出现了：

WordPress 按照默认情况安装，所以所有的表都用 UTF-8 存储数据；
WordPress 默认采用的浏览字符集是 UTF-8 (Options->Reading 中设置)，因此所有 WP 页面的 meta 中会说明 charset 是 utf-8；
所以浏览器会以 utf-8 方式显示所有的 WP 页面；这样一来 Write 的所有 Post，和 Comment 都会以 UTF-8 格式从浏览器发送给 Apache，再由 Apache 交给 PHP；
所以 WP 从所有的表单中得到的数据都是 utf-8 编码的；WP 不加转换的直接把这些数据发送给 MySQL；
MySQL 默认设置的 character_set_client 和 character_set_connection 都是 latin1，此时怪异的事情发生了，实际上是 utf-8 格式的数据，被“当作 latin1”转换成……居然还是转换成 latin1，然后再由这个 latin1 转换成 utf-8，这么两次转换，有一部分 utf-8 的字符就丢失了，变成 ??，最后输出的时候 character_set_results 默认是 latin1，也就输出为奇怪的东西了。
最神奇的还不是这个，如果 WordPress 中设置以 GB2312 格式阅读，那么 WP 发送给 MySQL 的 GB2312 编码的数据，被“当作 latin1”转换后，存进数据库的是一种奇怪的格式 (真的是奇怪的格式，mysqldump 出来就能发现，无论当作 utf-8 还是当作 gb2312 来读都是乱码)，但如果这种格式以 latin1 输出出来，居然又能变回 GB2312！

这会导致什么现象呢？WP 如果使用 MySQL 4.1 数据库，把编码改用 GB2312 就正常了，可惜，这种正常只是貌似正常。

如何解决问题如果你已经不耐烦了 (几乎是肯定的)，google 一下，会发现绝大部分的解答是，query 之前先执行一下：SET NAMES 'utf8'，没错，这是解决方案，但本文的目的是说明，这为什么是解决方案。

要保证结果正确，必须保证数据表采用的格式是正确的，也就是说，至少能够存放所有的汉字，那么我们只有两种选择，gbk 或者 utf-8，下面讨论 utf-8 的情况。

因为配置文件设置的 default_character_set 是 utf8，数据表默认采用的就是 utf-8 建立的。这也应该是所有采用 MySQL 4.1 的主机提供商应该采用的配置。所以我们要保证的只是客户端与 MySQL 交互之间指定编码的正确。

这只有两种可能，客户端以 gb2312 格式发送数据，或者以 utf-8 格式发送数据。

如果以 gb2312 格式发送:

SET character_set_client='gb2312'
SET character_set_connection='utf8' 或者
SET character_set_connection='gb2312'

都是可以的，都能够保证数据在编码转换中不出现丢失，也就是保证存储入数据库的是正确的内容。

怎么保证取出的是正确的内容呢？考虑到绝大部分客户端 (包括 WP)，发送数据的编码也就是它所希望收到数据的编码，所以:

SET character_set_results='gb2312'

可以保证取出给浏览器显示的格式就是 gb2312。

如果是第二种情况，客户端以 utf-8 格式发送 (WP 的默认情况)，可以采用下述配置:

SET character_set_client='utf8'
SET character_set_connection='utf8'
SET character_set_results='utf8'

这个配置就等价于 SET NAMES 'utf8'。

WP 应该作什么修改还是那句话，客户端要发给数据库什么编码的数据，数据库是不可能确切知道的，只能让客户端自己说明白，所以，WP 是必须发送正确的 SET... 给 MySQL 的。怎么发送最合适呢？台湾的 pLog 同仁给出了一些建议：

首先，测试服务器是否 >= 4.1，编译时是否加入了 UTF-8 支持；是则继续
然后测试数据库以什么格式存储 ($dbEncoding)；
SET NAMES $dbEncoding
对 于第二点，WP 的情况是不同的，按照上面的典型配置，只要用 WP，肯定数据库是用 UTF-8 存储的，所以要根据用户设置的以 GB2312 还是 UTF-8 浏览来判断 (bloginfo('charset'))，但这个值是要连接数据库以后才能得到的，所以效率最高的方式是连接数据库之后，根据这个配置设置一次 SET NAMES，而不必每次查询之前都设置一遍。

我的修改方式是这样的，在 wp_includes/wp-db.php 中增加:

function set_charset($charset)
{
// check mysql version first.
$serverVersion = mysql_get_server_info($this->dbh);
$version = explode('.', $serverVersion);
if ($version[0] < 4) return;

// check if utf8 support was compiled in
$result = mysql_query("SHOW CHARACTER SET like 'utf8'",
$this->dbh);
if (mysql_num_rows($result) < = 0) return;

if ($charset == 'utf-8' || $charset == 'UTF-8')
$charset = 'utf8';
@mysql_query("SET NAMES '$charset'", $this->dbh);
}

在 wp-settings.php 的 require (ABSPATH . WPINC . '/vars.php'); 后增加:

$wpdb->set_charset(get_bloginfo('charset'));

1. MySQL 4.1 在文字上有很大改进，它有了 Character Set 与 Collation 的慨念。

2. 在 MySQL 4.0 ，一般的程式都会将文字以拉丁文 ( latin) 来储存，就算我们输入中文字，结果仍是放在以拉丁文设置的文字栏里头，这对 MySQL 4.0 与以 MySQL 4.0 为基楚的程式来说，并不会有问题。

3. 可是 MySQL 4.1 的系统编码是预设用 UTF-8 的，当要 restore MySQL 4.0 的 backup 档到 MySQL 4.1 时，乱码就出现了。原因在于 MySQL 4.1 将 latin 码转换过来，而后转换是并不完全完美的，这导致了出现少量文字出现乱码现象。

4. 要解决这乱码问题并不难。首先，在 MySQL 4.0 备份时，先将所有文字栏变成 binary 类型，然后进行正常备份。第二步，可在 MySQL 4.1 里将刚才的备份 restore。最后，将较早前所变更到 binay 类型的文字栏，再次复原到文字类型。这样中文编码的问题就应该可以完全解决。

5. 将文字栏变更到 binay 类型时，必需设定 binary 栏的长度大过或等于 (>=) 文字栏的长度，否则资料会失去。

6. 另外，经这样升级的 MySQL 数据库，在 MySQL 4.1 里将会正常工作，就算是怎样 backup 与 restore 都不会再有乱码问题。
作者: MySQL 发布日期: 2005-12-14
mysql4.1是比较烦人，支持多语言的细化设置，再加上phpmyadmin2.6也比较笨，默认就是改不动的utf8，怎么弄都乱码。
好了，废话少说，我们来一步步解决这个问题：
1.修改/etc/my.cnf文件，改成这样：
[mysqld]
datadir=/var/lib/mysql
socket=/var/lib/mysql/mysql.sock
default-character-set=utf8

[mysql.server]
user=mysql
basedir=/var/lib

[mysqld_safe]
err-log=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid

注意：就是加入了一句default-character-set=utf8。

2./etc/init.d/mysqld restart 重新启动mysql；
3.打开phpmyadmin，选择lang为"Chines simplifies(zh-utf-8)",选择"MySQL 连接校对"为"utf8_general_ci "点“显示 MySQL 的运行信息”--“变量”，可以看到：
character set client utf8 utf8
character set connection utf8 utf8
character set database utf8 utf8
character set results utf8 utf8
character set server utf8 utf8
character set system utf8 utf8
collation connection utf8_general_ci utf8_general_ci
collation database utf8_general_ci utf8_general_ci
collation server utf8_general_ci utf8_general_ci
从这里可以看到character全部变成utf8了。
有人要问，为什么都要改成utf8呢？改成GB2312不行吗？
解释如下：
我也不想改成utf8，只是phpmyadmin2.6在mysql4.1的时候只会用utf8，连其他页面的charset也都是utf8，改成gb2312一定会乱码，我们只能凑phpmyadmin了。
只有在mysql3.23的时候，phpmyadmin才会多一个gb2312的页面charset，这时候是正常的。
3.将以前的mysql3的库文件导入mysql4.1的库
有两种情况：
一是从phpmyadmin上导入，这时候你要注意的是在选择库文件的页面左下脚有个“文件的字符集：”，默认是utf8，要改成gb2312，否则导进去乱码；
二是在linux下导入，这时候你需要先在库文件的头部加一行:
SET NAMES 'gb2312'; 注意最后也是;号，别漏了。
然后执行mysql -u用户名 -p密码 xxx.sql > 库名
导入完成以后再用phpmyadmin打开看，里面的中文字就是正确的。
4.从mysql4.1里导出库文件
一.用phpmyadmin导出
导出倒是问题不大，如果phpmyadmin的浏览页面里显示的中文是正常的，那么导出肯定也是正常的
二.在linux上导出
如果用mysqldump导出出现了乱码也没有关系，可以运行iconv来转换一下
iconv -c -f UTF-8 -t GB2312 库文件名 > 新的gb2312的库文件名

综上所述，你要注意：
1。尽量在需要导入的库文件的开头加入SET NAMES 'gb2312';告诉mysql你要导入的是一个gb2312的文件；
2。可能你需要这个：
SET NAMES 'utf8';
在登陆到mysql后用，把character的一些默认参数改到utf8上，有时可以减少一些困扰，不过也不是必须的。
在mysql上使用:
SHOW VARIABLES LIKE 'character_set_%';
用来查看当前的状态。
3.如果出现乱码也不要怕，一是你要注意留存原有的备份，二是用iconv来进行转化。
在正常使用之前注意做导入导出的测试，确保万无一失。

最后加一句：www.quicklinux.org原创文章，转载请注明出处。呵呵
邮件：support@quicklinux.org
作者: MySQL 发布日期: 2005-12-14
我升级了MYSQL到4.1.2，phpmyadmin用的是2.6.2。数据表里面有中文的字段中文都变成了乱码，导出数据也是乱码。我用以前的2.5.7没有问题，想问一下，应该在phpmyadmin的那个文件里改哪个设置一下才能显示出来的是正常的中文字？

和字符相关的变量中这几个和sql很有关系：
character_set_client
character_set_connection
character_set_results
此外就是数据库中对相应字段设置的charact set，如果没有对字段设置，缺省是table的charact set，table也没有指定则缺省使用database的。
上面3个变量的作用是这样的，client表示客户端发送过来的字符集，results表示发送到客户端的字符集（这两个分开是因为发送过来和发送过去的不一定是同一个客户端），connection则在客户端和数据库起一个连接作用。
具体是这样：比如我在mysql命令行设置client为gbk，connection为utf8，results为gbk，数据库为big5，
当我发送一个insert语句的时候，这个语句作为gbk代码，先转为utf8代码（connection），再转为big5（database）插入数据库。
而运行一个select语句的时候，从数据库得到的结果则相反的过程，由big5转为utf8，再转为gbk，你得到gbk的结果。
因此最主要的是让client和results和你使用的客户端一致。比如你的网页是utf8编码，你就要设置这两个为utf8。
而在mysql命令行的时候，我用的是2000，需要设置为gbk
而我们用的set names XXX，实际上就是同时设置这3个变量为XXX。
在这样的情况下，我们可以把一个数据库中的不同表或不同字段设为不同的字符集，只要上面3个设置正确，就可以在数据库中同时使用不同的字符集。
注意要保证你的数据库中的字符已经使用了正确的字符集，比如如果一开始你设置错误，插入数据后，本身数据的编码就是不正确的，然后即使设置改回来，也不可能得到正确的显示了。
还有一个是编码互相之间的兼容性，如果一个字符在gbk中有，在utf8中没有，那么在gbk－》utf8－》gbk的过程中，它就变成了“？”
再说一下具体解决的办法。
首 先要指定你的升级后的database及table及field的character set，一般来说我们用gb2312或者utf8的，如果不同时使用多种编码，只要指定database就可以，可以在建库的sql语句加上相应的 character set，在phpMyAdmin里也可以修改。
然后是导入旧数据。首先要确定自己的数据文件的编码。如果用phpMyAdmin导入，在界面上有文件编码的选项，一定要和数据文件的编码一致。
如果从mysql的命令行导入，就要自己设置上面说到的3个变量，set names xxx。
使用其它的客户端程序一样要注意。
这样就可以让旧数据转入新数据库后的编码才是正确的，如果这一步错了，后面不可能得到正确的显示。
然后是自己的程序，在连接后就可以执行一次set names xxx，根据你的网页编码而定。
这样基本就可以保证编码正确了。
你很有可能是导入的数据编码已经不对了。 

MYSQL数据库默认语言为瑞典语, 现有一GB2312字符的数据库.
结构OK. 为什么内容是乱码? 不重装数据库有办法解决码?

从MySQL 4.1开始引入的多语言支持确实很棒，而且一些特性已经超过了其他的数据库系统。不过我在测试过程中发现使用适用于MySQL 4.1之前的PHP语句操作MySQL数据库会造成乱码，即使是设置过了表字符集也是如此。我读了一下新的MySQL在线手册中第十章 "Character Set Support"后终于找到了解决方法并测试通过。

MySQL 4.1的字符集支持(Character Set Support)有两个方面：字符集(Character set)和排序方式(Collation)。对于字符集的支持细化到四个层次: 服务器(server)，数据库(database)，数据表(table)和连接(connection)。

查看系统的字符集和排序方式的设定可以通过下面的两条命令：

mysql> SHOW VARIABLES LIKE 'character_set_%';
+--------------------------+----------------------------+
| Variable_name | Value |
+--------------------------+----------------------------+
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
+--------------------------+----------------------------+
7 rows in set (0.00 sec)

mysql> SHOW VARIABLES LIKE 'collation_%';
+----------------------+-------------------+
| Variable_name | Value |
+----------------------+-------------------+
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
+----------------------+-------------------+
3 rows in set (0.00 sec)

上面列出的值就是系统的默认值。(很奇怪系统怎么默认是latin1的瑞典语排序方式)...

当我们按照原来的方式通过PHP存取MySQL数据库时，就算设置了表的默认字符集为utf8并且通过UTF-8编码发送查询，你会发现存入数据库的仍然是乱码。问题就出在这个connection连接层上。解决方法是在发送查询前执行一下下面这句：

SET NAMES 'utf8';

它相当于下面的三句指令：
SET character_set_client = utf8;
SET character_set_results = utf8;
SET character_set_connection = utf8;

再试试看，正常了吧？^_^ Enjoy!

具体讲
在你的查询前加一行：
                mysql_query("SET NAMES 'gb2312';",$this->con);

真应该把手册仔细看一遍.
和字符相关的变量中这几个和sql很有关系：
character_set_client
character_set_connection
character_set_results
此外就是数据库中对相应字段设置的charact set，如果没有对字段设置，缺省是table的charact set，table也没有指定则缺省使用database的。
上面3个变量的作用是这样的，client表示客户端发送过来的字符集，results表示发送到客户端的字符集（这两个分开是因为发送过来和发送过去的不一定是同一个客户端），connection则在客户端和数据库起一个连接作用。
具体是这样：比如我在mysql命令行设置client为gbk，connection为utf8，results为gbk，数据库为big5，
当我发送一个insert语句的时候，这个语句作为gbk代码，先转为utf8代码（connection），再转为big5（database）插入数据库。
而运行一个select语句的时候，从数据库得到的结果则相反的过程，由big5转为utf8，再转为gbk，你得到gbk的结果。
因此最主要的是让client和results和你使用的客户端一致。比如你的网页是utf8编码，你就要设置这两个为utf8。
而在mysql命令行的时候，我用的是2000，需要设置为gbk
而我们用的set names XXX，实际上就是同时设置这3个变量为XXX。
在这样的情况下，我们可以把一个数据库中的不同表或不同字段设为不同的字符集，只要上面3个设置正确，就可以在数据库中同时使用不同的字符集。
注意要保证你的数据库中的字符已经使用了正确的字符集，比如如果一开始你设置错误，插入数据后，本身数据的编码就是不正确的，然后即使设置改回来，也不可能得到正确的显示了。
还有一个是编码互相之间的兼容性，如果一个字符在gbk中有，在utf8中没有，那么在gbk－》utf8－》gbk的过程中，它就变成了“？”
再说一下具体解决的办法。
首 先要指定你的升级后的database及table及field的character set，一般来说我们用gb2312或者utf8的，如果不同时使用多种编码，只要指定database就可以，可以在建库的sql语句加上相应的 character set，在phpMyAdmin里也可以修改。
然后是导入旧数据。首先要确定自己的数据文件的编码。如果用phpMyAdmin导入，在界面上有文件编码的选项，一定要和数据文件的编码一致。
如果从mysql的命令行导入，就要自己设置上面说到的3个变量，set names xxx。
使用其它的客户端程序一样要注意。
这样就可以让旧数据转入新数据库后的编码才是正确的，如果这一步错了，后面不可能得到正确的显示。
然后是自己的程序，在连接后就可以执行一次set names xxx，根据你的网页编码而定。 

-----------------------------------------

mysql 导入乱码问题- -

This method works regardless of the size of your database. You must have SSH access to your server. On (gs) plans you can invoke SSH access from within your Control Panel. On (dv) plans you must enable Shell Access through Plesk.

这个方法推荐给具有大数据库的家伙，而且你必须有SSH权限，

方法一
使用phpmyadmin，这是最简单的了，修改mysql库的user表，不过别忘了使用PASSWORD函数。

方法二
使用mysqladmin，这是前面声明的一个特例。
mysqladmin -u root -p password mypasswd
输入这个命令后，需要输入root的原密码，然后root的密码将改为mypasswd。
把命令里的root改为你的用户名，你就可以改你自己的密码了。
当然如果你的mysqladmin连接不上mysql server，或者你没有办法执行mysqladmin，那么这种方法就是无效的，而且mysqladmin无法把密码清空。

下面的方法都在mysql提示符下使用，且必须有mysql的root权限：
方法三
mysql> Insert INTO mysql.user (Host,User,Password)
VALUES('%','jeffrey',PASSWORD('biscuit'));
mysql> FLUSH PRIVILEGES
确切地说这是在增加一个用户，用户名为jeffrey，密码为biscuit。
在《mysql中文参考手册》里有这个例子，所以我也就写出来了。
注意要使用PASSWORD函数，然后还要使用FLUSH PRIVILEGES。

方法四
和方法三一样，只是使用了REPLACE语句
mysql> REPLACE INTO mysql.user (Host,User,Password)
VALUES('%','jeffrey',PASSWORD('biscuit'));
mysql> FLUSH PRIVILEGES

方法五
使用SET PASSWORD语句，
mysql> SET PASSWORD FOR jeffrey@"%" = PASSWORD('biscuit');
拟也必须使用PASSWORD()函数，但是不需要使用FLUSH PRIVILEGES。

方法六
使用GRANT ... IDENTIFIED BY语句
mysql> GRANT USAGE ON *.* TO jeffrey@"%" IDENTIFIED BY 'biscuit';
这里PASSWORD()函数是不必要的，也不需要使用FLUSH PRIVILEGES。

注意： PASSWORD() [不是]以在Unix口令加密的同样方法施行口令加密。
MySQL 忘记口令的解决办法
如果 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 。

mysql密码清空
Windows:
1.用系统管理员登陆系统。
2.停止MySQL的服务。
3.进入命令窗口，然后进入MySQL的安装目录，比如我的安装目录是c:\mysql,进入C:\mysql\bin
4.跳过权限检查启动MySQL，
c:\mysql\bin>mysqld-nt --skip-grant-tables
5.重新打开一个窗口，进入c:\mysql\bin目录，设置root的新密码
c:\mysql\bin>mysqladmin -u root flush-privileges password "newpassword"
c:\mysql\bin>mysqladmin -u root -p shutdown
将newpassword替换为你要用的root的密码，第二个命令会提示你输入新密码，重复第一个命令输入的密码。
6.停止MySQL Server，用正常模式启动Mysql
7．你可以用新的密码链接到Mysql了。

Unix&Linux：
1.用root或者运行mysqld的用户登录系统；
2．利用kill命令结束掉mysqld的进程；
3．使用--skip-grant-tables参数启动MySQL Server
shell>mysqld_safe --skip-grant-tables &
4.为root@localhost设置新密码
shell>mysqladmin -u root flush-privileges password "newpassword"
5．重启MySQL Server

mysql修改密码
　　mysql修改，可在mysql命令行执行如下：
　　mysql -u root mysql
　　mysql> Update user SET password=PASSWORD("new password") Where user='name';
　　mysql> FLUSH PRIVILEGES;
　　mysql> QUIT

教你如何将MySQL数据库的密码恢复

因为MySQL密码存储于数据库mysql中的user表中，所以只需要将我windows 2003下的MySQL中的user表拷贝过来覆盖掉就行了。

在c:\mysql\data\mysql\(linux 则一般在/var/lib/mysql/mysql/)目录下有三个user表相关文件user.frm、user.MYD、user.MYI

user.frm //user表样式文件

user.MYD //user表数据文件

user.MYI //user表索引文件

为保险起见，三个都拷贝过来，不过其实如果之前在要恢复的那个MySQL上没有更改过表结构的话，只要拷贝user.MYD就行了

然后

#. /etc/rc.d/init.d/mysql stop
#. /etc/rc.d/init.d/mysql start
#mysql -u root -p XXXXXX

好了，可以用windows 2003下mysql密码登陆了

mysql>use mysql
mysql>update user set Password=PASSWORD('xxxxxx') where User='root';

这时候会出错，提示user表只有读权限

我分析了一下原因，只这样的，因为user.*文件的权限分配是windows 2003下的，在windows 2003下我ls -l一看权限是666

在linux下我一看，拷过来后权限变成了600(其实正常情况下600就行了，只不过这里的文件属主不是mysql，拷过来后的属主变为了 root,所以会出现权限不够，这时候如果你改成权限666则可以了，当然这样不好，没有解决问题的实质)，在 /var/lib/mysql/mysql/下ls -l看了一下

再

#chown -R mysql:mysql user.*
#chmod 600 user.*

//OK,DONE

重起一下MYSQL

重新连接

mysql>use mysql
mysql>update user set Password=PASSWORD('xxxxxx') where User='root';
mysql>FLUSH PRIVILEGES;

有一点值得注意:如果你windows 下mysql如果是默认配置的话，注意要还要执行

mysql>delete from user where User='';
mysql>delete from user where Host='%';
mysql>FLUSH PRIVILEGES;

好了，到这里恢复密码过程就完成了

这个方法么就是有点局限性，你必须也具备另外的user表文件

其他还有几种方法

其它方法一(这个是网上流传较广的方法,mysql中文参考手册上的)

1. 向mysqld server 发送kill命令关掉mysqld server(不是 kill -9),存放进程ID的文件通常在MYSQL的数据库所在的目录中。

killall -TERM mysqld

你必须是UNIX的root用户或者是你所运行的SERVER上的同等用户，才能执行这个操作。

2. 使用`--skip-grant-tables' 参数来启动 mysqld。 LINUX下：

/usr/bin/safe_mysqld --skip-grant-tables , windows下c:\mysql\bin\mysqld --skip-grant-tables

3. 然后无密码登录到mysqld server ，

>use mysql
>update user set password=password("new_pass") where user="root";
>flush privileges;

。你也可以这样做：

`
mysqladmin -h hostname -u user password 'new password''

4. 载入权限表：

`
mysqladmin -h hostname flush-privileges'

或者使用 SQL 命令

`FLUSH PRIVILEGES'

5.

killall -TERM mysqld

6.用新密码登陆

其它方法二

直接用十六进制编辑器编辑user.MYD文件

不过这个里面我要说明一点，我这里编辑的时候发现个问题，加密的密码串有些是连续存储的，有些的最后两位被切开了，后两位存储在后面其他地方.这一 点我还没想明白.还有注意一点就是编辑的是加密过的密码串，也就是说你还是需要另外有user表文件。这种方法和我最上面介绍的方法的区别在于，这种方法 直接编辑linux下的user表文件，就不需要重新改文件属主和权限了 

修正一下：我在Windows下的实际操作如下

1.关闭正在运行的MySQL。

2.打开DOS窗口，转到mysql\bin目录。

3.输入

mysqld-nt --skip-grant-tables

回车。如果没有出现提示信息，那就对了。

4.再开一个DOS窗口（因为刚才那个DOS窗口已经不能动了），转到mysql\bin目录。

5.输入mysql回车，如果成功，将出现MySQL提示符 >

6. 连接权限数据库

>use mysql;
(>是本来就有的提示符,别忘了最后的分号)

6.改密码：

> update user set password=password("123456") where user="root"; (别忘了最后的分号)

7.刷新权限（必须的步骤）

>flush privileges;

8.退出

> \q

9.注销系统，再进入，开MySQL，使用用户名root和刚才设置的新密码123456登陆。

据说可以用直接修改user表文件的方法：

关闭MySQL，Windows下打开Mysql\data\mysql，有三个文件user.frm,user.MYD,user.MYI找个知道密码的MySQL，替换相应的这三个文件，如果user表结构没改过，一般也没人去改，替换user.MYD就可以了。

也可以直接编辑user.MYD，找个十六进制编辑器，UltraEdit就有这个功能。关闭MySQL，打开user.MYD。将用户名root 后面的八个字符改为565491d704013245，新密码就是123456。或者将它们对应的十六进制数字，（左边那里，一个字符对应两个数字），改 为 00 02 02 02 02 02 02 02,这就是空密码，在编辑器右边看到的都是星号*，看起来很象小数点。重开MySQL，输入root和你的新密码。

　　ZackUrlocker今天在北京召开的一个小型记者会上表示：软件产业正在经历的革命绝非从单一产品向整体解决方案的转变，而是基于互联网的软件应用服务的兴起。同时，ZackUrlocker表示：即将发布的MySQL5.1将增加对XML的支持。

　　ZackUrlocker完全同意“Oracle是波音747，MySQL是丰田汽车”这个说法，“但要知道，丰田汽车可比波音747多得太多;很多人都可以购买一辆丰田汽车，但绝大多数的人不需要买一架波音747。”

/*

* 功能：数据备份/恢复文件简易方法
*    以日期为单位，一天一个备份文件，以当天最后备份为准
*    用提交表单的形式进行操作，
*   其中$_POST["tbl_name"]为预备份表名称数组
*   $_POST["sqlfile"]为预恢复数据文件的名称
*   注
 */

Mysql的优化原则1：

1、使用索引来更快地遍历表。
缺省情况下建立的索引是非群集索引，但有时它并不是最佳的。在非群集索引
下，数据在物理上随机存放在数据页上。合理的索引设计要建立在
对各种查询的分析和预测上。一般来说：
a.有大量重复值、且经常有范围查询（ > ,< ，> =,< =）和order by、group by发生的列，可考
虑建立群集索引；
b.经常同时存取多列，且每列都含有重复值可考虑建立组合索引；
c.组合索引要尽量使关键查询形成索引覆盖，其前导列一定是使用最频繁的列。索引虽有助于提高性能但不是索引越多越好，恰好相反过多的索引会导致系统低效。用户在表中每加进一个索引，维护索引集合就要做相应的更新工作。

一、问题的提出

　　在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统 提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。 对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的 SQL语句，提高系统的可用性。

　　在多数情况下，Oracle使用索引来更快地遍历表，优化器主要根据定义的索引来提高性能。但是，如果在SQL语句的where子句中写的 SQL代码不合理，就会造成优化器删去索引而使用全表扫描，一般就这种SQL语句就是所谓的劣质SQL语句。在编写SQL语句时我们应清楚优化器根据何种 原则来删除索引，这有助于写出高性能的SQL语句。