MySql数据库是中小型网站后台数据库的首选,因为它对非商业应用是免费的.网站开发者可以搭建一个"Linux+Apache+PHP+MySql" 平台,这是一个最省钱的高效平台.在使用MySql进行开发时,MySql自带的文档对于新手来说是份很好的参考资料.本文是我在使用MySql中的小小心得。

当前一般用户的开发环境多是Windows或Linux，用户可以到
http://www.mysql.com下载相关版本进行安装，在 windows中MySql以服务形式存在，在使用前应确保此服务已经启动，未启动可用net start mysql命令启动。而Linux中启动时可用“/etc/rc.d/init.d/mysqld start"命令，注意启动者应具有管理员权限。

刚安装好的MySql包含一个含空密码的root帐户和一个匿名帐户，这是很大的安全隐患，对于一些重要的应用我们应将安全性尽可能提高，在这里应把匿名帐户删除、 root帐户设置密码，可用如下命令进行：

如果要对用户所用的登录终端进行限制，可以更新User表中相应用户的Host字段，在进行了以上更改后应重新启动数据库服务，此时登录时可用如下类似命令：

上面命令参数是常用参数的一部分，详细情况可参考文档。此处的mydb是要登录的数据库的名称。

在进行开发和实际应用中，用户不应该只用root用户进行连接数据库，虽然使用root用户进行测试时很方便，但会给系统带来重大安全隐患，也不利于管理技术的提高。我们给一个应用中使用的用户赋予最恰当的数据库权限。如一个只进行数据插入的用户不应赋予其删除数据的权限。MySql的用户管理是通过 User表来实现的，添加新用户常用的方法有两个，一是在User表插入相应的数据行，同时设置相应的权限；二是通过GRANT命令创建具有某种权限的用户。其中GRANT的常用用法如下：

  若要给此用户赋予他在相应对象上的权限的管理能力，可在GRANT后面添加WITH GRANT OPTION选项。而对于用插入User表添加的用户，Password字段应用PASSWORD 函数进行更新加密，以防不轨之人窃看密码。对于那些已经不用的用户应给予清除，权限过界的用户应及时回收权限，回收权限可以通过更新User表相应字段，也可以使用REVOKE操作。

下面给出本人从其它资料(
www.cn-java.com)获得的对常用权限的解释：

全局管理权限：

FILE: 在MySQL服务器上读写文件。

PROCESS: 显示或杀死属于其它用户的服务线程。

RELOAD: 重载访问控制表，刷新日志等。

SHUTDOWN: 关闭MySQL服务。

数据库/数据表/数据列权限：

ALTER: 修改已存在的数据表(例如增加/删除列)和索引。

CREATE: 建立新的数据库或数据表。

DELETE: 删除表的记录。

DROP: 删除数据表或数据库。

INDEX: 建立或删除索引。

INSERT: 增加表的记录。

SELECT: 显示/搜索表的记录。

UPDATE: 修改表中已存在的记录。

特别的权限：

ALL: 允许做任何事(和root一样)。

USAGE: 只允许登录--其它什么也不允许做。

最后给出本人在RedHat9.0下的MySql操作演示：

选用数据库的root用户登录

其中test.sql是用vi编辑好的SQL脚本，其内容为：

运行已经编辑好的SQL脚本可以用source filename 或 . filename。

以上只是对新手的简单练习，要成为一个数据库好手，当以孜孜不倦地追求知识，不断地思考、尝试、再思考。

 来源：

在我接触的其他程序转换过程，报错的机会不少，原因也很多，我个人技术，PHP等环境问题....

个人感觉MySQL 4.1 与MySQL 5.0还是有相当大的区别，比如说是字符集。

 下面是我收集的一些材料：

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_connection='utf8' 或者  

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

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

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

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

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

WP 应该作什么修改

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

首先，测试服务器是否 >= 4.1，编译时是否加入了 UTF-8 支持；是则继续  

然后测试数据库以什么格式存储 ($dbEncoding)；  

对于第二点，WP 的情况是不同的，按照上面的典型配置，只要用 WP，肯定数据库是用 UTF-8 存储的，所以要根据用户设置的以 GB2312 还是 UTF-8 浏览来判断 (bloginfo('charset'))，但这个值是要连接数据库以后才能得到的，所以效率最高的方式是连接数据库之后，根据这个配置设置一次 SET NAMES，而不必每次查询之前都设置一遍。

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

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

可以将这个脚本放进crontab，每天凌晨执行一次，自动备份  

这个脚本每天最多只执行一次，而且只保留最近五天的备份在服务器上。

可以将那个脚本放进crontab，每天凌晨执行一次，自动备份  

那个脚本每天最多只执行一次，而且只保留最近五天的备份在服务器上。

   应该补齐全了，附上一些常见错误代码：
1005：创建表失败

1006：创建数据库失败

1007：数据库已存在，创建数据库失败

1008：数据库不存在，删除数据库失败

1009：不能删除数据库文件导致删除数据库失败

1010：不能删除数据目录导致删除数据库失败

1011：删除数据库文件失败

1012：不能读取系统表中的记录

1020：记录已被其他用户修改

1021：硬盘剩余空间不足，请加大硬盘可用空间

1022：关键字重复，更改记录失败

1023：关闭时发生错误

1024：读文件错误

1025：更改名字时发生错误

1026：写文件错误

1032：记录不存在

1036：数据表是只读的，不能对它进行修改

1037：系统内存不足，请重启数据库或重启服务器

1038：用于排序的内存不足，请增大排序缓冲区

1040：已到达数据库的最大连接数，请加大数据库可用连接数

1041：系统内存不足

1042：无效的主机名

1043：无效连接

1044：当前用户没有访问数据库的权限

1045：不能连接数据库，用户名或密码错误

1048：字段不能为空

1049：数据库不存在

1050：数据表已存在

1051：数据表不存在

1054：字段不存在

1065：无效的SQL语句，SQL语句为空

1081：不能建立Socket连接

1114：数据表已满，不能容纳任何记录

1116：打开的数据表太多

1129：数据库出现异常，请重启数据库

1130：连接数据库失败，没有连接数据库的权限

1133：数据库用户不存在

1141：当前用户无权访问数据库

1142：当前用户无权访问数据表

1143：当前用户无权访问数据表中的字段

1146：数据表不存在

1147：未定义用户对数据表的访问权限

1149：SQL语句语法错误

1158：网络错误，出现读错误，请检查网络连接状况

1159：网络错误，读超时，请检查网络连接状况

1160：网络错误，出现写错误，请检查网络连接状况

1161：网络错误，写超时，请检查网络连接状况

1062：字段值重复，入库失败

1169：字段值重复，更新记录失败

1177：打开数据表失败

1180：提交事务失败

1181：回滚事务失败

1203：当前用户和数据库建立的连接已到达数据库的最大连接数，请增大可用的数据库连接数或重启数据库

1205：加锁超时

1211：当前用户没有创建用户的权限

1216：外键约束检查失败，更新子表记录失败

1217：外键约束检查失败，删除或修改主表记录失败

1226：当前用户使用的资源已超过所允许的资源，请重启数据库或重启服务器

1227：权限不足，您无权进行此操作

1235：MySQL版本过低，不具有本功能

--转自