MySQL+PHP产生乱码原因：
◆ MySQL数据库默认的编码是utf8,如果这种编码与你的PHP网页不一致,可能就会造成MySQL乱码;
◆ MySQL中创建表时会让你选择一种编码,如果这种编码与你的网页编码不一致,也可能造成MySQL乱码;
◆ MySQL创建表时添加字段是可以选择编码的,如果这种编码与你的网页编码不一致,也可能造成MySQL乱码;
◆ 用户提交页面的编码与显示数据的页面编码不一致,就肯定会造成PHP页面乱码;
◆ 如用户输入资料的页面是big5码, 显示用户输入的页面却是gb2312,这种100%会造成PHP页面乱码;
◆ PHP页面字符集不正确;
◆ PHP连接MySQL数据库语句指定的编码不正确。
注意：
很多人都怀疑MySQL版本不一致会导致乱码,相信看了本说明你就不会这样认为了。
平时你在某些网站看到的文字可能有几种编码, 如你看到一个繁体字,它有可能是big5编码,也有 可能是utf-8编码的,更有可能是gb码的,没错,也就是说有简体编码的繁体字,也有繁体编码的简体字,一定要了解这一点。
如果你是做一个简体编码的网页,编码定为GB2312,如果有香港和台湾地区的访客提交繁体的信息,就可能会造成乱码,解决方法：
将网站编码设为 utf-8,这样可以 ......
MySQL+PHP产生乱码原因：
◆ MySQL数据库默认的编码是utf8,如果这种编码与你的PHP网页不一致,可能就会造成MySQL乱码;
◆ MySQL中创建表时会让你选择一种编码,如果这种编码与你的网页编码不一致,也可能造成MySQL乱码;
◆ MySQL创建表时添加字段是可以选择编码的,如果这种编码与你的网页编码不一致,也可能造成MySQL乱码;
◆ 用户提交页面的编码与显示数据的页面编码不一致,就肯定会造成PHP页面乱码;
◆ 如用户输入资料的页面是big5码, 显示用户输入的页面却是gb2312,这种100%会造成PHP页面乱码;
◆ PHP页面字符集不正确;
◆ PHP连接MySQL数据库语句指定的编码不正确。
注意：
很多人都怀疑MySQL版本不一致会导致乱码,相信看了本说明你就不会这样认为了。
平时你在某些网站看到的文字可能有几种编码, 如你看到一个繁体字,它有可能是big5编码,也有 可能是utf-8编码的,更有可能是gb码的,没错,也就是说有简体编码的繁体字,也有繁体编码的简体字,一定要了解这一点。
如果你是做一个简体编码的网页,编码定为GB2312,如果有香港和台湾地区的访客提交繁体的信息,就可能会造成乱码,解决方法：
将网站编码设为 utf-8,这样可以 ......
MySQL的timestamp类型自动更新问题
今天建了一个表，里面有一个列是timestamp类型，我本意是在数据更新时，这个字段的时间能自动更新。岂知对这个类型的值还不甚了解，导致出错。发现这个字段只是在这行数据建立的时候有值，在更新的却无变化。
查找资料，发现是我建表的语句有问题：
以下是代码片段：
CREATE TABLE `test` (
`t1` timestamp NOT NULL default CURRENT_TIMESTAMP,
`ww` varchar(5) NOT NULL
) ENGINE=MyISAM ;
而实际上，以下两个建表语句的效果是一样的：
以下是代码片段：
CREATE TABLE `test` (
`t1` TIMESTAMP NOT NULL ,
`ww` VARCHAR( 5 ) NOT NULL
) ENGINE = MYISAMCREATE TABLE `test` (
`t1` timestamp NOT NULL default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP,
`ww` varchar(5) NOT NULL
) ENGINE=MyISAM ;
比较之下，我的语句少了“on update CURRENT_TIMESTAMP”或多了“default CURRENT_TIMESTAMP”。如此一来，这个timestamp字段只是在数据insert的时间建立时间，而update时就不会有变化了。当然 ......
首先看MySQL 5.0参考手册中关于创建存储过程的语法说明：
CREATE
[DEFINER = { user | CURRENT_USER }]
PROCEDURE sp_name ([proc_parameter[,...]])
[characteristic ...] routine_body
proc_parameter:
[ IN | OUT | INOUT ] param_name type
type:
Any valid MySQL data type
characteristic:
LANGUAGE SQL
| [NOT] DETERMINISTIC
| { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
| SQL SECURITY { DEFINER | INVOKER }
| COMMENT 'string'
routine_body:
Valid SQL procedure statement
如果你对MySQL还不太熟悉的话，单单看这个语法结构当然不足以进行MySQL存储过程编程。我之前基本都是使用MS SQL SERVER，所以以下记录我熟悉MySQL存储过程的过程，也是重点介绍MS SQL SERVER与MySQL区别较大的地方。
第一步，当然是写个Hello Word的存储过程，如下：
CREATE PROCEDURE phelloword()
BEGIN
SELECT ......
通过分区（Partition）提升MySQL性能
作者：foxcai 来源:foxcai 的 Blog (2006-05-08 14:30:34)
通过分区（Partition）提升MySQL性能
——MySQL5.1新特性翻译系列
几年前，俺写过一篇题为“The Foundation of Excellent Performance”的文章(现在仍然可以在http://www.tdan.com/i016fe03.htm看到)，俺对SQL语句是影响数据库驱动系统性能的第一要素的观点有点质疑。其实在那时我在文章中就坚信数据库的物理设计在对高级数据库的性能影响上远比其他因素重要。同时俺还给大家看了Oracle的研究，他们解释了为什么拙劣的物理设计是数据库停机（无论是有计划的还是没计划的）背后的主要原因。这么多年都过来啦（幸好没多少人朝俺扔砖头），俺的观点是改变了一些，但在这点上俺还是坚持DBA如果想要高性能的数据库就必须在数据库的物理设计上多思考的观点，这样才能减少响应时间使终端用户满意而不是引来骂声一片。（陈朋奕语：不要那么严肃，嘿嘿）
俺今天这么激动又想写文章的原因是MySQL5.1的发布带来了设计超强动力数据库的强有力的武器，任何MySQL的 ......
innodb_buffer_pool_size
如果用Innodb，那么这是一个重要变量。相对于MyISAM来说，Innodb对于buffer size更敏感。MySIAM可能对于大数据量使用默认的key_buffer_size也还好，但Innodb在大数据量时用默认值就感觉在爬了。 Innodb的缓冲池会缓存数据和索引，所以不需要给系统的缓存留空间，如果只用Innodb，可以把这个值设为内存的70%-80%。和 key_buffer相同，如果数据量比较小也不怎么增加，那么不要把这个值设太高也可以提高内存的使用率。
innodb_additional_pool_size
这个的效果不是很明显，至少是当操作系统能合理分配内存时。但你可能仍需要设成20M或更多一点以看Innodb会分配多少内存做其他用途。
innodb_log_file_size
对于写很多尤其是大数据量时非常重要。要注意，大的文件提供更高的性能，但数据库恢复时会用更多的时间。我一般用64M-512M，具体取决于服务器的空间。
innodb_log_buffer_size
默认值对于多数中等写操作和事务短的运用都是可以的。如果经常做更新或者使用了很多blob数据，应该增大这个值。但太大了也是浪费内存，因为1秒钟总会 flush（这个词的中文怎么说呢？）一次，所以不需要设到超过1秒的需求。8M-16M一般应该够了。小的运用可以设� ......
在对mysql进行调试的时候，由于mysql存在query缓存，常常不能反映真实情况。
有时候，有没有使用FLUSH
QUERY
CACHE的权限；
在 query_cache_type 打开的情况下，如果你不想使用缓存，需要指明
select sql_no_cache id,name from tableName;
或者还有更简单的办法，修改一下sql里某个字母的大小写，（奇怪为什么这样也可以，但是就是可以）
这样就可以不使用缓存啦 ......
最新文章 : mysql