以下問題是關於選擇完全匹配（例如：INT）與使用varchar的「LIKE」匹配之間的速度。MySQL是像SELECT一樣昂貴的嗎？
有很大的區別嗎？我問這個問題的主要原因是因爲我試圖決定是否將ID從我當前的項目中刪除。
例如相反的：
http://mysite.com/article/391239/this-is-an-entry
更改爲：
http://mysite.com/article/this-is-an-entry
你認爲我會感受到從長遠來看，任何性能問題？我應該保留身份證嗎？
注：
我會用想保持用戶更容易記住。例如，如果他們寫入「http://mysite.com/article/this-is-an」，它將重定向到正確的。
關於頁數，可以說我是在79,230左右的應用程序。正在快速增長。喜歡可以說每天1640條目
INT比較將比字符串（varchar）比較更快。 LIKE比較更慢，因爲它涉及至少一個通配符。
在您的應用程序中這是否顯着是很難從您告訴我們的。除非它非常密集，即。你正在做這些比較的gazillions，我會清楚地爲你的用戶。
另一件需要考慮的事情是：用戶是否總是要輸入URL？或者他們只是要使用搜索引擎？現在我只是搜索，而不是嘗試和記住一個URL。這會使我成爲一名用戶不成問題。你的用戶喜歡什麼？你能告訴你的應用程序他們如何訪問你的網站？
首先，我認爲這兩種方式並不重要，是的，因爲LIKE子句涉及比直接比較更多的工作，所以速度會更慢，但速度在正常站點上可以忽略不計。
如果您要測量執行查詢所用的時間，則可以輕鬆測試此功能，但有plenty of examples可幫助您完成此部門。
若要從您的問題中解決問題，您必須問自己，您是否需要使用LIKE進行此查詢，因爲「這是一個條目」應該是唯一的，對嗎？
SELECT id, friendly_url, name, content FROM articles WHERE friendly_url = 'this-is-an-article';
我會使用LIKE讓用戶更容易記住。例如，如果他們寫「http://mysite.com/article/this-is-an」，它會重定向到正確的。 – MarioRicalde 2009-12-08 09:25:08
那你怎麼樣在數據庫中：「這是一篇文章」和「這是一個不需要的頁面」？ – hsz 2009-12-08 09:28:52
我非常懷疑用戶會從內存中輸入一個網址，大多數都是通過Google或用戶書籤獲取的。 – 2009-12-08 09:29:00
INT更快。
在字符串的情況下，我認爲是因爲你找this-is-an-entry，不是this-is-an-entry-and-something你不應該LIKE但只是=選擇查詢。
如果你把一個索引放在varchar字段上，它應該沒問題（性能明智），這取決於你將擁有多少頁面。另外，您必須更仔細並將字符串消毒至，防止sql注入，例如在您的查詢中只允許a-z，0-9， - ，_等。
我還是喜歡一個整數ID，因爲它是更快，更安全，格式更改爲更好，如： http://mysite.com/article/21-this-is-an-entry.html
至於說，比較INT < VARCHAR，如果表是索引的字段，你'然後搜索也會有幫助，因爲服務器不需要動態創建手動索引。
有一件事將有助於驗證您的查詢速度和意義是EXPLAIN。您可以使用它來顯示您的查詢正在使用哪些索引，以及執行時間。
要回答你的問題，如果可以使用文章ID（即INT）上的精確匹配來構建系統，那麼它將比如果您嘗試使用LIKE聲明。 LIKE顯然會工作，但我不想在其上運行一個大型的高流量站點。
「SELECT * FROM x WHERE = 391239」查詢將比「SELECT * FROM x WHERE ='some-key'」更快，這反過來會比「SELECT * FROM x WHERE LIKE 「％某些鍵％」」（野生卡的存在不會使不同的堆
有多快兩倍快 - ？很可能十倍快？但是可能的話，這裏真正的問題是1）它是否重要，2）你是否應該首先使用LIKE。
1）有關係嗎 我可能會說不。如果您確實擁有391,239多篇獨特的文章/頁面 - 並且假設您獲得了可比的流量級別，那麼這可能只是您可能遇到的許多縮放問題之一。不過，我保證情況並非如此，因此，除非您獲得100萬和1個網頁瀏覽量，否則您不必擔心一百萬個網頁瀏覽量。
2）如果您甚至可以使用像這樣 號如果頁面/文章的標題/名稱的網址是「鼻涕蟲」的一部分，它必須是唯一的。如果不是的話，那麼你就是在搜索引擎優化方面投入自己的腳步，併爲自己寫一篇維護夢魘。如果標題/名稱是唯一的，那麼您可以使用「WHERE title ='some-page'」，並確保標題列上具有唯一索引。
編輯使用喜歡的網址的
你的計劃是完全徹底的瘋狂。如果有人訪問，會發生什麼事
yoursite.com/articles/the
您是否返回開始「the」的所有頁面的列表？接下來會發生什麼，如果：
作者A創建
yoursite.com/articles/stackoverflow-is-massive
兩天後作者B創建
yoursite.com/articles/stackoverflow-is-massively-flawed
不僅會是相當憤怒，他的文章已經HI-擡高，所有的他可能已經發送出去的perma-links將會被打破，而且Google將永遠不會給你的文章任何合理的頁面排名，因爲內容不斷變化並且有效地削弱了自己。
有時候，有一個很好的理由，你從未在別的地方見過你的驚人新「想法/特徵/發明/節省時間」。
偉大的關於文章「hi-jacking」的可能性。在我參與的一個項目中，我遇到過類似的情況，這是一個噩夢。 – 2012-02-23 14:43:37
有一些事情要考慮：
對數據庫進行搜索的類型將是一個「索引查找」，使用索引，大部分時間尋找單列。
使用ints而不是字符串，這種類型的單行精確匹配操作不會明顯更快，但對於任何實際用途，它們的成本基本相同。
你可以做的是以下優化，使用完全匹配（無通配符）搜索數據庫，這與使用int索引一樣快。如果沒有匹配進行模糊搜索（使用通配符進行搜索），則此代價更昂貴，但另一方面更爲罕見，並且可能產生多個結果。如果您想要進行最佳匹配，則需要一種排名結果形式。
僞代碼：
注：記住，模糊的網址不是從SEO的角度來看建議，因爲人們可以使用多個URL，將分離鏈接你的網站您的網頁排名，而不是增加它。
但速度有多快？這就是問題所在。 – MarioRicalde 2009-12-08 09:24:01
非常快...... :)如果你想更準確 - 它取決於機器等。 – hsz 2009-12-08 09:26:43
主要問題是，應用程序實際上增長速度超過預期。所以有一次它可以讓我們說1,000,000個條目，並且仍然越來越多。也許我應該保持整數？ – MarioRicalde 2009-12-08 09:28:30