MySql現(xiàn)在用longtext數(shù)據(jù)類型是否合理？謝邀。從題主的描述來看，這里是兩個需求：博客編輯和分詞、審核。首先對于內(nèi)容的編輯需求，使用MySQL是合適的，這里只有數(shù)據(jù)的增刪改查操作，關(guān)系數(shù)據(jù)庫都

MySql現(xiàn)在用longtext數(shù)據(jù)類型是否合理？

謝邀。

從題主的描述來看，這里是兩個需求：博客編輯和分詞、審核。

首先對于內(nèi)容的編輯需求，使用MySQL是合適的，這里只有數(shù)據(jù)的增刪改查操作，關(guān)系數(shù)據(jù)庫都可以很好的處理，速度也不會慢。

但是對于分詞搜索，就不是關(guān)系型數(shù)據(jù)庫可以解決的問題了，一般需要單獨的搜索引擎組件來承擔(dān)這塊的需求，有代表性的開源產(chǎn)品是solr。以上是個人淺見，希望可以給樓主幫助。

為什么MySQL在數(shù)據(jù)庫較大的時候分頁查詢很慢，如何優(yōu)化？

使用合理的分頁方式以提高分頁的效率

正如樓主所說，分頁查詢在我們的實際應(yīng)用中非常普遍，也是最容易出問題的查詢場景。比如對于下面簡單的語句，一般想到的辦法是在name，age，register_time字段上創(chuàng)建復(fù)合索引。這樣條件排序都能有效的利用到索引，性能迅速提升。

如上例子，當(dāng) LIMIT 子句變成 “LIMIT 100000， 50” 時，此時我們會發(fā)現(xiàn)，只取50條語句為何會變慢?

原因很簡單，MySQL并不知道第 100000條記錄從什么地方開始，即使有索引也需要從頭計算一次，因此會感覺非常的慢。

通常，我們在做分頁查詢時，是可以獲取上一頁中的某個數(shù)據(jù)標(biāo)志來縮小查詢范圍的，比如時間，可以將上一頁的最大值時間作為查詢條件的一部分，SQL可以優(yōu)化為這樣：

若對你有所幫助，歡迎點贊、關(guān)注支持哦。