遊戲開發者 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，哪怕生寫兩條查詢，查回來在用PHP合併數據。
7.使用錯誤的資料型別
　　INT，TinyINT，VARCHAR，CHAR，TEXT這些欄位型別的合理選用無可厚非。
　　而Date、DateTime、TIMESTAMP這三種類型，在大型應用中是絕對不可以使用的，而是要用INT(10) UNSIGNED代替。
　　一個是性能，另外就是應用中尤其是PHP對UNIX_TIMESTAMP時間戳的轉換實在太方便了。用Date要輸出各種時間格式反而麻煩。
8.在SELECT查詢中使用*
　　共勉
9.索引不足或過度索引
　　索引是必須的，但是如果索引都解決不了的查詢，考慮memcache或者nosql解決方案吧。
10.不備份
　　這條是作者湊數麼?
11.另外：不考慮其他資料庫
　　這條相當正確。應用程式中不僅要針對應用程式選擇其他資料庫，甚至要針對特定的業務類型，在同一套應用程式中並行使用多種資料庫。就算不是資料庫，而是其他各種快取、記憶體儲存等解決方案。

以上就介紹了遊戲開發者 PHP開發者常犯的10個MySQL錯誤更正剖析，包括了遊戲開發者方面的內容，希望對PHP教程有興趣的朋友有所幫助。