PHP 开发者应该注意的 10 个 MySQL 错误

　
    1.使用 MyISAM 而不是 InnoDB
　　完全错误，反驳理由：
　　首先原文说

MyISAM 是默认使用的，而实际上到了 MySQL 5.5.x，InnoDB 已经成为了

默认的表引擎。
　　另外，简单的使用

InnoDB 不是解决所有问题的方法，盲目的使用甚至会使应用性能

下降

10%乃至 40%。

　　最佳方法还是针对具体业务具体处理，例如论坛中版块表，新闻分类表，各种码表等
长时间不操作的表，还是要用性能优异的

MyISAM 引擎。

　　而需要用到事务处理的例如用户、账目、流水等严格要求数据完整性和时序性的，则需
要用

InnoDB 引擎，并且应用也要用好事务处理机制。当然，事务处理必然要带来大量的性

能损耗，但是这在简单高并发应用上是必须的。
　　最后，外键约束在公共

web 互联网应用上一般是不用的，因为他会严重影响性能。数

据完整性还是靠程序员或者应用架构本身的健壮来维护。而正规的第三范式只是在企业内部
MIS 系统和 12306 这种网站上使用。
　　

2.使用 PHP 的 mysql 方法

　　不完全错，但要酌情选用：
　　

mysqli 固然好，但是不是所有的服务器都为 PHP 编译了 mysqli 的支持。

　　当你的应用如果是能确定只用自己部署的服务器，而应用也是完全自己开发，则
mysqli 是最好的选择。
　　但是一旦你的应用有可能部署在虚拟主机或者由其他人部署

(例如分布式项目)，还是

老老实实使用

mysql 函数集吧，好好封装一下或者使用成熟框架杜绝 sql 注入。

　　

3.不过滤用户输入

　　这一点不用说了，要么

MagicQuote，要么选用成熟框架。sql 注入老话题了。

　　

4.不使用 UTF-8

　　大部分情况下对，但也要认真考虑：
　　要知道，一个

UTF-8 字符占 3 个字节，所以比 GBK 等其他编码的文件大 33%。换句话

说，相同的网页用

UTF-8 编码如果是 100KB，那么换成 GBK 编码则只有 66KB。所以即便

你的

PHP 确定要用 UTF-8，那么前端页面也要根据情况选择需要的编码。但是，如果 PHP

用

UTF-8，前端模版是 GBK，再加上模版引擎不强大，那么转码工作够你受的。所以尽可

能的选用自己需要的编码，而不是简单的选择

UTF-8 了事。

　　最后啰嗦一句：

UTF-8 下：strlen("我")=3，而 GBK 下：strlen("我")=2

　　

5.该用 SQL 的地方使用 PHP

　　同样酌情考虑：
　　例如，有些人习惯在建表时，默认值填写

CURRENT_TIMESTAMP，用来达到注册时

间、发帖时间的效果。

 或者在时间判断的 SQL 语句中，写类似 SELECT x FROM tab1 

WHERE regdate 正确做法是：不要使用 MySQL 的任何时间函数，而是在应用里计算时间。
如果是分布式应用，一定要有时间服务器来统一管理时间。
　　而文中说的一些

MySQL 数学函数 ，也是要慎用。因为在大型应用中，数据库的负担往

往是最大的，而复杂的

WHERE 语句又是造成慢查询的元凶。所以，要把计算尽可能的放在

廉价的、不影响全局稳定的应用服务器上，而不是核心数据库上。
　　

6.不优化查询

　　这点也不用说了，大型应用上甚至不允许使用各种

JOIN，哪怕生写两条查询，查回来