切換到mysqli或留在mysql？

我們在這裏有一個應用程序，一直在開發（現在正在生產）一年多。其中總共有500多個mysql_*電話。切換到mysqli或留在mysql？

是否值得切換的mysql_*的所有在代碼中mysqli_*

是否值得追的所有可能（而且很可能會）來對錯誤？

我從類似這樣的問題中看到：Changing this from MySQL to MySQLi?剛剛在每個mysql*調用之後加上i會導致我發生很多錯誤。這是值得我的時間嗎？

mysql_*可能會在很長一段時間內（即使在貶低的謠言之中），所以它真的值得程序員有時間有條不紊地切換嗎？

See also this discussion

來源

2011-08-26 Neal

PHP團隊即將棄用未來PHP版本中的'mysql_ *'函數。閱讀：http://news.php.net/php.internals/53799 – Buddy

@布迪，如果通過「即將到來」你的意思是「也許，可能在幾年內，考慮開始考慮」。通過文件進行教育是所有將在短期/中期內發生的事情。 – salathe

@salathe，如果是「短/中期」，你的意思是1 - 2年，你不應該在新項目中使用'musql_ *'。棄用是PHP中的這種擴展會發生的一切。 – Buddy

引述manual for ext/mysqli：

mysqli擴展具有許多優點，在MySQL擴展是關鍵的增強功能：

面向對象的接口

支持預處理語句

支持多種語句

支持交易
個
增強的調試功能

嵌入式服務器支持

注意：如果你正在使用MySQL版本4.1.3或更高版本，強烈建議您使用這個擴展。

如果您只需要其中一個功能並且可以承受重構，那麼是的，就去做吧。如果你不需要任何這些功能，那麼不要這樣做。如果沒有任何好處，沒有理由重構。

On a sidenote, the rumors are true. ext/mysql will likely be deprecated（儘管在撰寫本文時沒有人可以說，它肯定不會被5.4棄用，並且它可能永遠可用作pecl擴展）無論如何，你不應該開始任何新項目與ext/mysql了，當你有一個優秀的擴展開始。

另見http://blog.ulf-wendel.de/2012/php-mysql-why-to-upgrade-extmysql/

來源

2011-08-26 15:10:01 Gordon

我已經可以做交易（慢慢地）：http://stackoverflow.com/questions/2708237/php-mysql-transactions-examples和代碼似乎工作正常 – Neal

OOP支持是跛腳，準備語句很慢，多條語句易於注入，嵌入式服務器很荒謬。老實說，沒有真正的好處。 –

@戈登，**將**替換爲**很可能**。你不能說我們可以在PHP-land上發生什麼**。 – salathe

在我看來，庫MySQLi的好處是，當它在一個面向對象的方式使用，並用準備好的語句。你也可以使用程序風格來獲得一些額外的多功能性，比如圍繞事務處理的漂亮包裝函數，但是我認爲除非你重寫了大量的代碼來利用它們，否則我認爲這還不夠。

如果您要努力轉換爲OO代碼或準備好的語句，那麼您最好轉換爲更靈活的PDO而不是MySQLi。

更新2013年1月

剛剛發現這個古老的答案，並在2011年8月評論跟帖下面我說，這是不值得mysql_query()電話轉換爲mysqli_query()缺席伴隨移動到準備好的發言。它現在需要IS開始朝這個方向移動，因爲mysql_*()擴展從PHP 5.5開始已被棄用，並且最終將被刪除。

來源

2011-08-26 15:00:53

是的，但值得花時間切換一個具有500多個'mysql_ *'調用的應用程序嗎？ – Neal

@Neal我會說這不是，除非你需要使用MySQLi改進的事務提交/回滾包裝等。 –

PDO是一個不錯的選擇，但是在共享服務器中你不能使用suhosin.sql.user_prefix http ：//www.hardened-php.net/suhosin/configuration.html#suhosin.sql.user_prefix – corretge

在我看來，你不應該直接在你的邏輯中使用mysql_ *函數。你應該寫一個包裝。所以當你想把mysql_*切換到mysqli_*時，你只需要改變包裝的代碼。

來源

2011-08-26 15:08:15 xdazz

？如何如此以及如何防止我的代碼中的錯誤？ – Neal

防止錯誤取決於您的測試。 – xdazz

呵呵？那是什麼意思？ – Neal

MySQLi比MySQL有一些性能優勢。實際上建議使用MySQLi而不是MySQL。你也可以做程序風格。

您可以創建應用程序的新分支並將代碼更改爲mysqli_*函數。這應該是非常簡單的，在這樣做的時候，你會檢查你的數據庫訪問代碼，這可能有助於在切換到mysqli之後繼續進行重構。如果它太麻煩了，您已經從數據庫訪問代碼中的客戶端庫改進版中受益。

來源

2011-08-26 15:09:04 hakre

「MySQLi比MySQL有一些性能優勢」？那是新聞，你從哪裏得到這些信息？它似乎總是相反的。 – Pacerier

棄用轉/ MySQL的是不是傳聞。

但是，這不是你真正的問題。

您的主要問題是，您在全部代碼中使用裸API調用，而不是使用某個智能庫來處理SQL查詢。

所以，你最好開始開發這樣一個庫或獲得一個現成的庫，然後重寫你的代碼來使用它的調用。

君不見，這一切都是重複的東西

$res=mysql_query("SELECT STUFF"); 
while($row = mysql_fetch){ 
    $var=$row['col']; 
}

是令人難以置信的無聊？
爲什麼不使用一些的單行樣

$data = $db->getRow("SELECT stuff");

這是短，可以有很多的像查詢日誌記錄，計數，調試，錯誤處理和這樣的功能？

而且，因爲使用這樣的庫，只有在那裏你將需要更改任何API調用將只有這個庫代碼的地方的副作用。

來源

2011-08-26 15:10:34

如果您有很多電話那麼我建議你實現你的數據庫調用（選擇或建築物）的一個抽象層，然後是轉換開始。

在我的類似練習中最大的好處是，mysqli提供了參數化語句，允許您將mysql_real_escape_string等放在後面。但是從一個到另一個的地圖並不是一對一的。

來源

2011-08-26 15:11:33 dkretz

你是第二個說'使用抽象層'的人，我該怎麼做？ – Neal

PDO是一個抽象層。它提供了一個類，其方法和屬性更接近程序語言中發生的情況，通常在概念上更豐富和更一致。或者，例如我寫的是一個類，我可以用$ db-> SqlExecute（$ sql），SqlRows（$ sql），SqlOneRow（$ sql），SqlExists（$ sql）和SqlOneValue（$ SQL）。只是封裝你可以舒適的模式。我個人的偏好是在SQL和PHP之間有一個非常薄的過濾器。 – dkretz

@Neal PDO是非常蹩腳的抽象層。最好找到更可靠的東西 –

建議：如果你打算做一個開關，不要切換到mysqli，而是切換到使用PDO。如果您必須切換到mysqli，請確保以PHP5 OO方式使用它。除非你喜歡意外的連接擠壓，否則不要同時使用mysqli OO和舊的mysql，或者同時使用舊的mysql和PDO。

來源

2011-08-26 15:40:34 Ray

切換到mysqli或留在mysql？

回答

相關問題