PHP开发者常犯的10个MySQL错误更正剖析
程序员文章站
2022-06-02 09:23:34
1.使用myisam而不是innodb 完全错误，反驳理由： 首先原文说myisam是默认使用的，而实际上到了mysql 5.5.x，innodb已经成为了默认的表...
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，哪怕生写两条查询，查回来在用php合并数据。
7.使用错误的数据类型
int，tinyint，varchar，char，text这些字段类型的合理选用无可厚非。
而date、datetime、timestamp这三种类型，在大型应用中是绝对不可以使用的，而是要用int(10) unsigned代替。
一个是性能，另外就是应用中尤其是php对unix_timestamp时间戳的转化实在太方便了。用date要输出各种时间格式反而麻烦。
8.在select查询中使用*
共勉
9.索引不足或者过度索引
索引是必须的，但是如果索引都解决不了的查询，考虑memcache或者nosql解决方案吧。
10.不备份
这条是作者凑数么?
11.另外：不考虑其他数据库
这条相当正确。应用中不仅要针对应用选择其他数据库，甚至还要针对具体的业务类型，在同一套应用中并行使用多种数据库。哪怕不是数据库，而是其他各种缓存、内存存储等解决方案。
完全错误，反驳理由：
首先原文说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，哪怕生写两条查询，查回来在用php合并数据。
7.使用错误的数据类型
int，tinyint，varchar，char，text这些字段类型的合理选用无可厚非。
而date、datetime、timestamp这三种类型，在大型应用中是绝对不可以使用的，而是要用int(10) unsigned代替。
一个是性能，另外就是应用中尤其是php对unix_timestamp时间戳的转化实在太方便了。用date要输出各种时间格式反而麻烦。
8.在select查询中使用*
共勉
9.索引不足或者过度索引
索引是必须的，但是如果索引都解决不了的查询，考虑memcache或者nosql解决方案吧。
10.不备份
这条是作者凑数么?
11.另外：不考虑其他数据库
这条相当正确。应用中不仅要针对应用选择其他数据库，甚至还要针对具体的业务类型，在同一套应用中并行使用多种数据库。哪怕不是数据库，而是其他各种缓存、内存存储等解决方案。