再談PHP開(kāi)發(fā)者常犯的10個(gè)MySQL錯誤

發(fā)布時(shí)間:2012-1-18 11:52    發(fā)布者:1046235000
關(guān)鍵詞: MySQL , PHP開(kāi)發(fā)者 , 錯誤
新聞來(lái)源:原創(chuàng )
最近看到一篇文章:《PHP開(kāi)發(fā)者常犯的10個(gè)MySQL錯誤》,發(fā)現文中不少內容陳舊,隨著(zhù)時(shí)間推移技術(shù)發(fā)展變化而變得不適用。為了防止誤導新手,特本著(zhù)與時(shí)俱進(jìn)的精神寫(xiě)出此文,絕非對原文作者的不尊重。

1.使用MyISAM而不是InnoDB
完全錯誤,反駁理由:
首先原文說(shuō)MyISAM是默認使用的,而實(shí)際上到了MySQL 5.5.x,InnoDB已經(jīng)成為了默認的表引擎。

另外,簡(jiǎn)單的使用InnoDB不是解決所有問(wèn)題的方法,盲目的使用甚至會(huì )使應用性能下降10%乃至40%。

最佳方法還是針對具體業(yè)務(wù)具體處理,例如論壇中版塊表,新聞分類(lèi)表,各種碼表等長(cháng)時(shí)間不操作的表,還是要用性能優(yōu)異的MyISAM引擎。
而需要用到事務(wù)處理的例如用戶(hù)、賬目、流水等嚴格要求數據完整性和時(shí)序性的,則需要用InnoDB引擎,并且應用也要用好事務(wù)處理機制。當然,事務(wù)處理必然要帶來(lái)大量的性能損耗,但是這在簡(jiǎn)單高并發(fā)應用上是必須的。

最后,外鍵約束在公共web互聯(lián)網(wǎng)應用上一般是不用的,因為他會(huì )嚴重影響性能。數據完整性還是靠程序員或者應用架構本身的健壯來(lái)維護。而正規的第三范式只是在企業(yè)內部MIS系統和12306這種網(wǎng)站上使用。

2.使用PHP的mysql方法
不完全錯,但要酌情選用:
mysqli固然好,但是不是所有的服務(wù)器都為PHP編譯了mysqli的支持。
當你的應用如果是能確定只用自己部署的服務(wù)器,而應用也是完全自己開(kāi)發(fā),則mysqli是最好的選擇。
但是一旦你的應用有可能部署在虛擬主機或者由其他人部署(例如分布式項目),還是老老實(shí)實(shí)使用mysql函數集吧,好好封裝一下或者使用成熟框架杜絕sql注入。

3.不過(guò)濾用戶(hù)輸入
這一點(diǎn)不用說(shuō)了,要么MagicQuote,要么選用成熟框架。sql注入老話(huà)題了。

4.不使用UTF-8
大部分情況下對,但也要認真考慮:
要知道,一個(gè)UTF-8字符占3個(gè)字節,所以比GBK等其他編碼的文件大33%。換句話(huà)說(shuō),相同的網(wǎng)頁(yè)用UTF-8編碼如果是100KB,那么換成GBK編碼則只有66KB。所以即便你的PHP確定要用UTF-8,那么前端頁(yè)面也要根據情況選擇需要的編碼。但是,如果PHP用UTF-8,前端模版是GBK,再加上模版引擎不強大,那么轉碼工作夠你受的。所以盡可能的選用自己需要的編碼,而不是簡(jiǎn)單的選擇UTF-8了事。
最后啰嗦一句:UTF-8下:strlen("我")=3,而GBK下:strlen("我")=2

5.該用SQL的地方使用PHP
同樣酌情考慮:
例如,有些人習慣在建表時(shí),默認值填寫(xiě)CURRENT_TIMESTAMP,用來(lái)達到注冊時(shí)間、發(fā)帖時(shí)間的效果。 或者在時(shí)間判斷的SQL語(yǔ)句中,寫(xiě)類(lèi)似SELECT x FROM tab1 WHERE regdate < UNIX_TIMESTAMP()。那么我只能說(shuō),你為系統埋下了很隱蔽的BUG。因為數據庫和應用往往不在同一臺機器上,時(shí)間很容易出現偏差。當你一套應用的時(shí)間參照不準確時(shí),就會(huì )出現很大的問(wèn)題。
正確做法是:不要使用MySQL的任何時(shí)間函數,而是在應用里計算時(shí)間。如果是分布式應用,一定要有時(shí)間服務(wù)器來(lái)統一管理時(shí)間。
而文中說(shuō)的一些MySQL數學(xué)函數 ,也是要慎用。因為在大型應用中,數據庫的負擔往往是最大的,而復雜的WHERE語(yǔ)句又是造成慢查詢(xún)的元兇。所以,要把計算盡可能的放在廉價(jià)的、不影響全局穩定的應用服務(wù)器上,而不是核心數據庫上。

6.不優(yōu)化查詢(xún)
這點(diǎn)也不用說(shuō)了,大型應用上甚至不允許使用各種JOIN,哪怕生寫(xiě)兩條查詢(xún),查回來(lái)在用PHP合并數據。

7.使用錯誤的數據類(lèi)型
INT,TinyINT,VARCHAR,CHAR,TEXT這些字段類(lèi)型的合理選用無(wú)可厚非。
而Date、DateTime、TIMESTAMP這三種類(lèi)型,在大型應用中是絕對不可以使用的,而是要用INT(10) UNSIGNED代替。
一個(gè)是性能,另外就是應用中尤其是PHP對UNIX_TIMESTAMP時(shí)間戳的轉化實(shí)在太方便了。用Date要輸出各種時(shí)間格式反而麻煩。

8.在SELECT查詢(xún)中使用*
共勉

9.索引不足或者過(guò)度索引
索引是必須的,但是如果索引都解決不了的查詢(xún),考慮memcache或者nosql解決方案吧。

10.不備份
這條是作者湊數么?

11.另外:不考慮其他數據庫
這條相當正確。應用中不僅要針對應用選擇其他數據庫,甚至還要針對具體的業(yè)務(wù)類(lèi)型,在同一套應用中并行使用多種數據庫。哪怕不是數據庫,而是其他各種緩存、內存存儲等解決方案。
本文地址:http://selenalain.com/thread-85375-1-1.html     【打印本頁(yè)】

本站部分文章為轉載或網(wǎng)友發(fā)布,目的在于傳遞和分享信息,并不代表本網(wǎng)贊同其觀(guān)點(diǎn)和對其真實(shí)性負責;文章版權歸原作者及原出處所有,如涉及作品內容、版權和其它問(wèn)題,我們將根據著(zhù)作權人的要求,第一時(shí)間更正或刪除。
您需要登錄后才可以發(fā)表評論 登錄 | 立即注冊

相關(guān)視頻

關(guān)于我們  -  服務(wù)條款  -  使用指南  -  站點(diǎn)地圖  -  友情鏈接  -  聯(lián)系我們
電子工程網(wǎng) © 版權所有   京ICP備16069177號 | 京公網(wǎng)安備11010502021702
快速回復 返回頂部 返回列表
午夜高清国产拍精品福利|亚洲色精品88色婷婷七月丁香|91久久精品无码一区|99久久国语露脸精品|动漫卡通亚洲综合专区48页