ǰλã >> SQL >> PHP?发?常?ʮ个MySQL错?
  ϸ

PHP?发?常?ʮ个MySQL错?

ȶȣ288   ʱ䣺2016-05-05 12:14:57.0
PHP?发?常?10个MySQL错?

容陈旧,随着时间推移??展变化?变得不适用。为了防止?导新手,特本?与时俱进的精神写出?文,绝非对原文作者的不尊重??/p>

1.使用MyISAM而不是InnoDB
完全错?,反驳理由:
首先原文说MyISAM?认使用的,?实际上到了MySQL 5.5.x,InnoDB已经成为了默认的表引擎??br style="margin: 0px; padding: 0px;">
另?,简单的使用InnoDB不是解决?有问题的方法,盲?使用甚至会使应用性能下降10%乃至40%?br style="margin: 0px; padding: 0px;">
?佳方法还?对具体业务具体?理,例?论坛?块表,新闻分类表,各种码表等长时间不操作的表,还??用?能优异的MyISAM引擎?br style="margin: 0px; padding: 0px;">而需要用到事务?理的例?用户、账??流水等严格要求数据完整性和时序性的,则?要用InnoDB引擎,并且应用也要用好事务?理机制?当然,事务处理必然要带来大量的性能损?,但是这在?单高并发应用上是必须的??br style="margin: 0px; padding: 0px;">
?后,外键约束在公共web互联网应用上??不用的,因为他会严重影响性能。数?整?还?程序员或者应用架构本?健壮来维护???规的?范式?在企业内部MIS系统?2306这?网站上使用??br style="margin: 0px; padding: 0px;">
2.使用PHP的mysql方法
不完全错,但要酌情?用?br style="margin: 0px; padding: 0px;">mysqli固然好,但是不是?有的服务器都为PHP编译了mysqli的支持??br style="margin: 0px; padding: 0px;">当你的应用?果是能确定只用自己部署的服务?而应用也?全自己开发,则mysqli?好的选择?br style="margin: 0px; padding: 0px;">但是?旦你的应用有?部署在虚拟主机或者由其他人部署(例?分布式项?,还???实实使用mysql函数集吧,好好封装一下或者使用成熟?架杜绝sql注入?br style="margin: 0px; padding: 0px;">
3.不过滤用户输?/span>
这一点不用?了,要么MagicQuote,?么?用成熟框架。sql注入老话题了?br style="margin: 0px; padding: 0px;">
4.不使用UTF-8
大部分情况下对,但也要?真?虑?br style="margin: 0px; padding: 0px;">要知道,?个UTF-8字???节,?以比GBK等其他编码的文件?3%。换句话说,相同的网页用UTF-8编码如果?00KB,那么换成GBK编码则只?6KB。所以即便你的PHP?要用UTF-8,那么前??要根?况?择?要的编码。但?如果PHP用UTF-8,前?版是GBK,再加上模版引擎不强大,那么?工作够你受的。所以尽?的?用??要的编码,?不?单的选择UTF-8了事?br style="margin: 0px; padding: 0px;">?后啰嗦一句:UTF-8下:strlen("?)=3,?GBK下:strlen("?)=2

5.该用SQL的地方使用PHP
同样酌情考虑?br style="margin: 0px; padding: 0px;">例?,有些人习惯在建表时,默认?填写CURRENT_TIMESTAMP,用来达到注册时间?发帖时间的效果?或?在时间判断的SQL??写类似SELECT x FROM tab1 WHERE regdate < UNIX_TIMESTAMP()。那么我?说,你为系统埋下了很隐蔽的BUG。因为数?和应用往?不在同一台机器上,时间很容易出现偏差。当你一套应用的时间参照不准?,就会出现很大的???br style="margin: 0px; padding: 0px;">正确做法?不?使用MySQL的任何时间函数,而是在应用里计算时间。?果是分布式应??定?有时间服务器来统?管理时间?br style="margin: 0px; padding: 0px;">而文??的一些MySQL数?函数 ,也??慎用。因为在大型应用?数据库的负担???大的,??杂的WHERE?又是造成慢查询的元凶。所以,要把计算尽可能的放在廉价的?不影响全局稳定的应用服务器上,而不?心数?上??br style="margin: 0px; padding: 0px;">
6.不优化查?/span>
这点也不用?了,大型应用上甚至不允?使用各?JOIN,哪怕生写两条查?查回来在用PHP合并数据?br style="margin: 0px; padding: 0px;">
7.使用错?的数??/span>
INT,TinyINT,VARCHAR,CHAR,TEXT这些字?类型的合理?用无可厚非?br style="margin: 0px; padding: 0px;">而Date、DateTime、TIMESTAMP这三种类型,在大型应用中?对不?使用的,而是要用INT(10) UNSIGNED代替?br style="margin: 0px; padding: 0px;">??性能,另外就?用中尤其是PHP对UNIX_TIMESTAMP时间戳的?实在?便了。用Date要输出各种时间格式反而麻烦??br style="margin: 0px; padding: 0px;">
8.在SELECT查???
共勉

9.索引不足或?过度索?/span>
索引?须的,但??果索引都解决不了的查?考虑memcache或?nosql解决方?吧??br style="margin: 0px; padding: 0px;">
10.不??/span>
这条?者凑数么?br style="margin: 0px; padding: 0px;">
11.另?:不考虑其他数据?/span>
这条相当正确。应用中不仅要针对应用?择其他数据库,甚至还?针?具体的业务类型,在同?套应用中并?使用多?数据库?哪怕不??,?是其他各?缓存、内存存储等解决方?

  ؽ