DB需要變得多大才能讓PHP/mySQL變得很慢？

Question

我想知道是否有任何開發者在那裏有經驗做這件事：

查詢變得很慢之前，您可以有多少行（在一列，1列，主鍵）？這是我不需要擔心的事情嗎？我可能永遠不會超過5000個左右。我沒有足夠的經驗知道。

Answer 1

此答案更多地基於您的標題「DB需要變得多大才能讓PHP/mySQL顯得很慢」。

PHP ...

如果你取一排，然後所有的時間是在MySQL。如果你正在讀取整個表格，那麼很多費用都在PHP中。 5000行不壞。一百萬行將會很慢，可能會耗盡內存。即使有一個十億表中的行

MySQL的

SELECT * FROM tbl WHERE primary_key = 'constant'; 

將是 '瞬間'。

SELECT * FROM tbl WHERE non_indexed_column = 'constant'; 

將開始緩慢，在5000行，將採取「太長」在百萬行，需要幾小時或幾天，如果你有一個十億行。

SELECT * FROM tbl WHERE indexed_uuid = 'constant'; 

雖然這是'即時'，但隨着表的增長，它會變成I/O界限。 UUID非常隨機，因此緩存是一個問題。當索引足夠小以適應RAM時，這表現良好。隨着指數變大，聲明變慢。 More on the evils of UUIDs。

換句話說，您刪除了重要信息 - 即涉及UUID。

爲什麼有1列表檢查UUID？爲什麼不在其他表中有一個索引，並用它來檢查。性能將幾乎相同（如果不是，可以緩存，如果不是，則爲I/O綁定）。

Answer 2

如果它被索引（它應該是;作爲表中唯一的字段，它應該是主鍵），就數據庫容量而言，您擁有大量的呼吸空間。在技​​術上它基於你的服務器和軟件配置，但即使是MySQL，也不會在單行的UUID和5000行的單個表上打破汗水。

在PHP的一端，它也取決於你的服務器資源和你的連接的容量與你的請求佔用的帶寬相比......但是如果你在一個不太可能存儲超過5,000個記錄，似乎不太可能相關的PHP將有容量問題（只要您的客戶提出了一個合理的請求數）。

一對夫婦的音符，但：

你似乎在暗示客戶端將被生成UUID，然後在服務器上驗證...這（Web客戶端手機端加油站客戶端？？？）並不是真正的身份驗證，也不是真實性的保證。目前還不清楚你的用例是什麼，但你可能想退一步，爲這個令牌定義你的目標，並且尋找解決相同問題的人。如果您生成類似API密鑰或身份驗證令牌的東西，那麼簡單的共享UUID可能不是最好的解決方法。無論如何，這應該發生在SSL上，否則你會輕易地將你的憑證發給任何正在傾聽你的請求的人。

更重要的是，根據您的令牌是否需要在會話中保持持久性，這也是我的描述中不清楚的地方，您可能不需要數據庫持久性。像redis這樣的內存商店可能是值得研究的東西，雖然我再也看不到這種印象，根據您的估計，性能將成爲瓶頸。

考慮到你所說的話，估計容量是不可能的，但是我認爲你不太可能會遇到來自技術堆棧的任何瓶頸。