MySQL的“SET NAMES x”字符集问题分析
MySQL的字符集问题。Windows下可通过修改my.ini内的
CODE:
# CLIENT SECTION
[mysql]
default-character-set=utf8
#
SERVER SECTION
[mysqld]
default-character-set=utf8
这
两个字段来更改数据库
的
默认字符集。第一个是客户端默认的字符集，第二个是服务器端默认的字符集。假设我们把两个都设为utf8，然后在MySQL Command Line
Client里面输入“show variebles like“character_set_%”;”，可看到如下字符：
character_set_client
latin1
character_set_connection latin1
character_set_database
utf8
character_set_results latin1
character_set_server utf8
character_set_system
utf8
其中的utf8随着我们上面的设置而改动。此时，要是我们通过采用UTF-8的PHP程序从数据库里读取数据，很有可能
是一串“?????”或者是其他乱码。网上查了半天，解决办法倒是简单，在连接数据库之后，读取数据之前，先执行一项查询“SET NAMES
UTF8”，即在PHP里为
mysql_query("SET NAMES UTF8");
即可显示正常（只要数据库里
信息的字符正常）。为什么会这样？这句查询“SET NAMES UTF8”到底是什么作用？
到MySQL命令行输入“SET
NAMES UTF8;”，然后执行“show variebles
like“character_set_%”;”，发现原来为latin1的那些变量“character_set_client”、
“character_set_connection”、“character_set_results”的值全部变为utf8了，原来是这3个变量在捣
蛋。查阅手册，上面那句等于
看看这3个变量的作用：
信息输入路径：client→connection→server；
信
息输出路径：server→connection→results。
换句话说，每个路径要经过3次改变字符集编码。以出现乱码的输出为
例，server里utf8的数据，传入connection转为latin1，传入results转为latin1，utf-8页面又把results
转过来。如果两种字符集不兼容，比如latin1和utf8，转化过程就为不可逆的，破坏性的。所以就转不回来了.
但这里要声明一
点，“SET NAMES UTF8”作用只是临时的，MySQL重启后就恢复默认了。
接下来就说到MySQL在服务器上的配置问题了。岂不是我
们每次对数据
相关文档：
使用Ports方式在FreeBSD下配置MySQL,Apache,PHP
郁闷了好几天,终于在FreeBSD下将MySQL,Apache,PHP的环境培植好了.下边把配置步骤和注意点罗列在下边,和大家分享.
FreeBSD版本是7.3,MySQL版本是5.0.90,Apache版本是2.2.14（1.3.42）,PHP版本是5.2.12.我的安装顺序是先MySQL,然后安装Apache和PHP,一般是安装� ......
1 Apache
修改 documentroot 根目录
directory 访问根目录权限
directoryindex 默认首页 ......
MySQL的自带引擎肯定是够用了，但是在有些情况下，其他的引擎可能要比手头所用更适合完成任务。如果愿意的话，你甚至可以使用MySQL++ API来创建自己的数据库引擎，就像打穿气缸装上自己的化油器。现在让我们来看看你该如何选择引擎，以及如何在可用引擎之间切换。
选择你的引擎
你能用的数据� ......
apache的静态/动态编译在apache+php+mysql的应用
我想大家有不少都成功实现apache+php+mysql，网上的文章也有不少，但我发现不少文章都是抄来抄去，并且
没有说明白编译的方式，有的索性apache1.3的编译方法原封不动的搬过来套在apache2.0，显然误导一些菜鸟 ！
我今天就以apache+mysql+php说一下静态编译和DSO动态编 ......
这两天正在测MYSQL的性能，按照MYSQL文档中推荐的设置，修改了几个系统变量
innodb_buffer_pool_size=1G
innodb_log_file_size=250M
innodb_log_buffer_size=8M
结果MYSQL崩了。mysql客户端能登录，但只要执行任何命令，mysqld立刻崩掉。
开始还以为是innodb_buffer_pool_size等几个参数设得太大了，可是调整了几次� ......
