对反驳PHP开发者常犯的10个MysqL错误感兴趣的小伙伴，下面一起跟随编程之家 jb51.cc的小编两巴掌来看看吧！
最近看到一篇文章：《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 < UNIX_TIMESTAMP()。那么我只能说，你为系统埋下了很隐蔽得BUG。因为数据库和应用往往不在同一台机器上，时间很容易出现偏差。当你一套应用得时间参照不准确时，就会出现很大得问题。 正确做法是：不要使用MysqL得任何时间函数，而是在应用里计算时间。如果是分布式应用，一定要有时间服务器来统一管理时间。 而文中说得一些MysqL数学函数 ，也是要慎用。因为在大型应用中，数据库得负担往往是最大得，而复杂得WHERE语句又是造成慢查询得元凶。所以，要把计算尽可能得放在廉价得、不影响全局稳定得应用服务器上，而不是核心数据库上。

6.不优化查询
这点也不用说了，大型应用上甚至不允许使用各种JOIN，哪怕生写两条查询，查回来在用PHP合并数据。

7.使用错误得数据类型
INT，TinyINT，VARCHAR，CHAR，TEXT这些字段类型得合理选用无可厚非。 而Date、DateTime、TIMESTAMP这三种类型，在大型应用中是绝对不可以使用得，而是要用INT(10) UNSIGNED代替。 一个是性能，另外就是应用中尤其是PHP对UNIX_TIMESTAMP时间戳得转化实在太方便了。用Date要输出各种时间格式反而麻烦。

8.在SELECT查询中使用*
共勉

9.索引不足或者过度索引
索引是必须得，但是如果索引都解决不了得查询，考虑memcache或者nosql解决方案吧。

10.不备份
这条是作者凑数么？

11.另外：不考虑其他数据库
这条相当正确。应用中不仅要针对应用选择其他数据库，甚至还要针对具体得业务类型，在同一套应用中并行使用多种数据库。哪怕不是数据库，而是其他各种缓存、内存存储等解决方案。 原文链接：https://www.f2er.com/php/527951.html