我的經驗是，大量的相關文章+合理的站內鏈接+穩定的更新頻率。
如何做好seo優化策略可參考如下方法搭罩：
在搜索引擎優化中，SEO策略影響到最終的優化效果。SEO策略不管對中小網站還是大型網站都是重要的，而對於大型網站，制定一個好的SEO策略尤為重要。
第一部分：關鍵詞分析
關鍵詞分析是所有SEO必須掌握的一門功課，大型網站雖然有海量的數據，但是每個頁面都需要進行關鍵詞分析，除了SEO之外，策劃、編輯也需要具備一定的關鍵詞分析能力。
關鍵詞分析的基本原則：
1、調查用戶的搜索習慣：這是一個重要的方面，只有了解用戶的搜索習慣，才能把我用戶的搜索需求，用戶喜歡搜索什麼?用什麼搜索引擎?等等
2、關鍵詞不能過於寬泛：關鍵詞過於寬泛會導致競爭激烈，耗費大量時間卻不一定得到想要的效果，並且可能降低了關鍵詞的相關性。
3、關鍵詞不能過冷：想想，沒有用戶搜索的關鍵詞，還值得去優化嗎?
4、關鍵詞要與頁面內容保持高度的相關性：這樣既有利於優化又有利於用戶。
關鍵詞挑選的步驟：
1、確定核心關鍵詞：我們應該考慮的是哪一個詞或者兩個詞能夠最准確的描述網頁的內容?哪一個詞用戶搜索次數最多?
2、核心關鍵詞定義上的擴展：例如核心關鍵詞的別名、僅次於核心關鍵詞的組合等、核心關鍵詞的輔助等。
3、模擬用戶思維設計關鍵詞：把自己假想為用戶，那麼我會去搜索什麼關鍵詞呢?
4、研究競爭者的關鍵詞：分析一下排名佔有優勢的競爭對手的網頁，他們都使用了什麼關鍵詞?
第二部分：頁面逆向優化
為什麼要做逆向優化?因為在大型網站中，頁面的優化價值一般不同於中小網站。考慮到各種綜合因素(例如品牌、頁面內容、用戶體驗等)，大型網站的頁面優化價值大多數呈現逆向順序，即：最終頁>專題頁>欄目頁>頻道頁>首頁。
如何針對各頁面進行關鍵詞分配呢?通常情況是這樣的：
1、最終頁：針對長尾關鍵詞;
2、專題頁：針對熱門關鍵詞，例如"周傑倫";
3、欄目頁：針對固定關鍵詞，例如"音樂試聽";
4、頻道頁：針對核心關鍵詞，例如"音樂";
5、首頁：不分配關鍵詞，而是以品牌為主。
在進行關鍵詞分配後，我們可以在最終頁中添加匹配的內鏈作為輔助，這是大型網站內鏈的優勢。
第三部分：前端搜索引擎友好，包括UI設計的搜索友好和前端代碼的搜索友好兩點
1、首先來看UI設計的搜索引擎友好：主要是做到導航清晰，以及flash和圖片等的使用，一般來說，導航以及帶有關鍵詞的部分不適合使用flash及圖片，因為大多數搜索引擎無法抓取flash及圖片中的文字。
2、然後是前端代碼的搜索引擎友好：
a、代碼的簡潔性：搜索引擎喜歡簡潔的html代碼，這樣更有利於分析。
b、重要信息靠前：指帶關鍵詞的及經常更新的信息盡量選擇出現在html的靠前位置。
c、過濾干擾信息：大型網站的頁面一般比較復雜，各種廣告、合作、交換內容以及其他沒有相關性的信息比較多，我們應該選擇使用js、iframe等搜索引擎無法識別的代碼過濾掉這一部分信息。
d、代碼的基礎SEO：這是基礎的SEO工作，避免html錯誤以及語義化標簽。
第四部分：內部鏈接策略
為什麼要強調內部鏈接策略?因為內鏈具有以下優勢：
1、大型網站海量的數據使內鏈的優勢遠遠大於外鏈。外鏈的數量可能幾千幾萬幾十萬，但是大型網站擁有成百萬上千萬甚至上億的海量網頁內容，如果用這些海量的網頁做內鏈的建設，優勢是很明顯的。
2、網站內的網頁間導出鏈接是一件很容易的事知兆鬧情。
3、提高搜索引擎對網站的爬行索引效率，增強收錄，也有利於PR的傳遞。
4、集中主題，使該主題的關鍵詞在搜索引擎中具有排名優勢。
第五部分：外部鏈接策略
在強調大型網站的內鏈建猜搜設的同時也不能太忽視了外鏈的建設。外鏈的建設雖然沒有中小網站那麼重要，但是也具有很高的價值。通常可以通過交換鏈接、製造鏈接誘餌、投放帶鏈接的軟文等方法來建設外鏈。
1、來看交換鏈接應該要遵循哪些原則：
a、鏈接文字中包含關鍵詞;b、盡量與相關性高的站點、頻道交換鏈接;c、對方網站導出鏈接數量不能過多，過多的話沒有太大的價值;d、避免與未被收錄以及被搜索引擎懲罰的網站交換鏈接
2、製造鏈接誘餌：製造鏈接誘餌是一件省力的工作，這使得對方網站主動的為我們添加鏈接。製造鏈接誘餌的技巧很多，但是可以用兩個字來概括：創意。
3、帶鏈接的軟文投放。指的是在商務推廣或者為專門為了得到外鏈而進行的帶鏈接的軟文投放。
第六部分:網站地圖策略
有很多大型網站不重視網站地圖的建設，不少大型網站的網站地圖只是敷衍了事，做一個擺設。其實網站對於大型網站是很重要的，大型網站海量的數據、復雜的網站導航結構、極快的更新頻率使得搜索引擎並不能完全抓取所有的網頁。這就是為什麼有的大型網站擁有百萬千萬甚至上億級的數據量，但是卻只被搜索引擎收錄了網站數據量的一半、三分之一甚至更少的一個重要原因。連收錄都保證不了，怎麼去做排名?
Html地圖：
1、為搜索引擎建立一個良好的導航結構。
2、Html地圖中可以分為橫向和縱向導航，橫向導航主要是頻道、欄目、專題等鏈接，縱向導航主要是針對關鍵詞。
3、每個頁面都有指向網站地圖的鏈接。
Xml網站地圖：主要針對Google、yahoo、live等搜索引擎。因為大型網站數據量太大，單個的sitemap會導致sitemap.xml文件太大，超過搜索引擎的容忍度。所以我們要將sitemap.xml拆分為數個，每個拆分後的sitemap.xml則保持在搜索引擎建議的范圍內。
第七部分:搜索引擎友好寫作策略
搜索引擎友好寫作是創造海量數據對取得好的搜索引擎排名的很關鍵的一部分。而SEO人員不可能針對每個網頁都提出SEO建議或者方案，所以對寫作人員的培訓尤為重要。如果所有寫作人員都按照搜索引擎友好的原則去寫作，則產生的效果是很恐怖的。
1、對寫作人員要進行反復培訓：寫作人員不是SEO，沒有經驗，不可能一遍就領悟SEO的寫作技巧。所以要對寫作人員進行反復的培訓才能達到效果。
2、創造內容先思考用戶會去搜索什麼，針對用戶的搜索需求而寫作。
3、重視title、meta寫作：例如Meta雖然在搜索引擎的權重已經很低，但是不好的meta寫作例如堆積關鍵詞、關鍵詞與內容不相關等行為反而會產生負作用。而Title的權重較高，盡量在Title中融入關鍵詞。
4、內容與關鍵詞的融合：在內容中要適當的融入關鍵詞，使關鍵詞出現在適當的位置，並保持適當的關鍵詞密度。
5、為關鍵詞加入鏈接很重要：為相關關鍵詞加入鏈接，或者為本網頁出現的其他網頁的關鍵詞加入鏈接，可以很好的利用內鏈優勢。
6、為關鍵詞使用語義化標簽：
第八部分:日誌分析與數據挖掘
日誌分析與數據挖掘常常被我們所忽視，其實不管是大型網站還是中小網站，都是一件很有意義的工作。只是大型網站的日誌分析和數據挖掘工作難度要更高一些，因為數據量實在太大，所以我們要具備足夠的耐心來做該項工作，並且要有的放矢。
1、網站日誌分析：網站日誌分析的的種類有很多，如訪問來源、瀏覽器、客戶端屏幕大小、入口、跳出率、PV等。跟SEO工作最相關的主要有以下三種：a、搜索引擎流量導入;b、搜索引擎關鍵詞分析;c、用戶搜索行為統計分析
2、熱點數據挖掘：我們可以通過自身的網站日誌分析以及一些外在的工具和SEO自己對熱點的把握能力來進行熱點數據的挖掘。熱點數據的挖掘主要有以下手段：a、把握行業熱點，可以由編輯與SEO共同完成;b、預測潛在熱點，對信息的敏感度要求較高，能夠預測潛在的熱門信息。c、自己創造熱點，如炒作等;d、為熱點製作專題
第九部分:為關鍵詞創作專題
除了最終頁面，各種針對熱門的關鍵詞所製作的專題應該作為網站的第二大搜索引擎流量來源。我們在對熱點數據進行挖掘後，就可以針對這些熱門關鍵詞製作專題了。製作的專題頁的內容從何而來?我們一般通過程序實現對應關鍵詞相關的信息進行篩選聚合，這樣就使得內容與關鍵詞高度匹配，為用戶、為搜索引擎都提供了所需要的內容。
當然，僅僅建立一個專題而沒有輔助手段是很難保證專題的搜索引擎排名的，我們可以通過文章內鏈、頻道頁推薦、或者最終頁的專題推薦來獲得鏈接達到效果。
1、為熱點關鍵詞製作專題
2、關鍵詞相關信息的聚合
3、輔以文章內鏈導入鏈接
2. 如何優化操作大數據量資料庫
下面以關系資料庫系統Informix為例，介紹改善用戶查詢計劃的方法。
1．合理使用索引
索引是資料庫中重要的數據結構，它的根本目的就是為了提高查詢效率。現在大多數的資料庫產品都採用IBM最先提出的ISAM索引結構。索引的使用要恰到好處，其使用原則如下：
●在經常進行連接，但是沒有指定為外鍵的列上建立索引，而不經常連接的欄位則由優化器自動生成索引。
●在頻繁進行排序或分組（即進行group by或order by操作）的列上建立索引。
●在條件表達式中經常用到的不同值較多的列上建立檢索，在不同值少的列上不要建立索引。比如在雇員表的「性別」列上只有「男」與「女」兩個不同值，因此就無必要建立索引。如果建立索引不但不會提高查詢效率，反而會嚴重降低更新速度。
●如果待排序的列有多個，可以在這些列上建立復合索引（compound index）。
●使用系統工具。如Informix資料庫有一個tbcheck工具，可以在可疑的索引上進行檢查。在一些資料庫伺服器上，索引可能失效或者因為頻繁操作而使得讀取效率降低，如果一個使用索引的查詢不明不白地慢下來，可以試著用tbcheck工具檢查索引的完整性，必要時進行修復。另外，當資料庫表更新大量數據後，刪除並重建索引可以提高查詢速度。
2．避免或簡化排序
應當簡化或避免對大型表進行重復的排序。當能夠利用索引自動以適當的次序產生輸出時，優化器就避免了排序的步驟。以下是一些影響因素：
●索引中不包括一個或幾個待排序的列；
●group by或order by子句中列的次序與索引的次序不一樣；
●排序的列來自不同的表。
為了避免不必要的排序，就要正確地增建索引，合理地合並資料庫表（盡管有時可能影響表的規范化，但相對於效率的提高是值得的）。如果排序不可避免，那麼應當試圖簡化它，如縮小排序的列的范圍等。
3．消除對大型錶行數據的順序存取
在嵌套查詢中，對表的順序存取對查詢效率可能產生致命的影響。比如採用順序存取策略，一個嵌套3層的查詢，如果每層都查詢1000行，那麼這個查詢就要查詢10億行數據。避免這種情況的主要方法就是對連接的列進行索引。例如，兩個表：學生表（學號、姓名、年齡……）和選課表（學號、課程號、成績）。如果兩個表要做連接，就要在「學號」這個連接欄位上建立索引。
還可以使用並集來避免順序存取。盡管在所有的檢查列上都有索引，但某些形式的where子句強迫優化器使用順序存取。下面的查詢將強迫對orders表執行順序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
雖然在customer_num和order_num上建有索引，但是在上面的語句中優化器還是使用順序存取路徑掃描整個表。因為這個語句要檢索的是分離的行的集合，所以應該改為如下語句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
這樣就能利用索引路徑處理查詢。
4．避免相關子查詢
一個列的標簽同時在主查詢和where子句中的查詢中出現，那麼很可能當主查詢中的列值改變之後，子查詢必須重新查詢一次。查詢嵌套層次越多，效率越低，因此應當盡量避免子查詢。如果子查詢不可避免，那麼要在子查詢中過濾掉盡可能多的行。
5．避免困難的正規表達式
MATCHES和LIKE關鍵字支持通配符匹配，技術上叫正規表達式。但這種匹配特別耗費時間。例如：SELECT ＊ FROM customer WHERE zipcode LIKE 「98_ _ _」
即使在zipcode欄位上建立了索引，在這種情況下也還是採用順序掃描的方式。如果把語句改為SELECT ＊ FROM customer WHERE zipcode >「98000」，在執行查詢時就會利用索引來查詢，顯然會大大提高速度。
另外，還要避免非開始的子串。例如語句：SELECT ＊ FROM customer WHERE zipcode[2，3]>「80」，在where子句中採用了非開始子串，因而這個語句也不會使用索引。
6．使用臨時表加速查詢
把表的一個子集進行排序並創建臨時表，有時能加速查詢。它有助於避免多重排序操作，而且在其他方面還能簡化優化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>「98000」
ORDER BY cust.name
如果這個查詢要被執行多次而不止一次，可以把所有未付款的客戶找出來放在一個臨時文件中，並按客戶的名字進行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然後以下面的方式在臨時表中查詢：
SELECT ＊ FROM cust_with_balance
WHERE postcode>「98000」
臨時表中的行要比主表中的行少，而且物理順序就是所要求的順序，減少了磁碟I/O，所以查詢工作量可以得到大幅減少。
注意：臨時表創建後不會反映主表的修改。在主表中數據頻繁修改的情況下，注意不要丟失數據。
7．用排序來取代非順序存取
非順序磁碟存取是最慢的操作，表現在磁碟存取臂的來回移動。SQL語句隱藏了這一情況，使得我們在寫應用程序時很容易寫出要求存取大量非順序頁的查詢。
有些時候，用資料庫的排序能力來替代非順序的存取能改進查詢。
實例分析
下面我們舉一個製造公司的例子來說明如何進行查詢優化。製造公司資料庫中包括3個表，模式如下所示：
1．part表
零件號?????零件描述????????其他列
（part_num）?（part_desc）??????（other column）
102，032???Seageat 30G disk?????……
500，049???Novel 10M network card??……
……
2．vendor表
廠商號??????廠商名??????其他列
（vendor _num）?（vendor_name） （other column）
910，257?????Seageat Corp???……
523，045?????IBM Corp?????……
……
3．parven表
零件號?????廠商號?????零件數量
（part_num）?（vendor_num）?（part_amount）
102，032????910，257????3,450,000
234，423????321，001????4，000，000
……
下面的查詢將在這些表上定期運行，並產生關於所有零件數量的報表：
SELECT part_desc，vendor_name，part_amount
FROM part，vendor，parven
WHERE part.part_num=parven.part_num
AND parven.vendor_num = vendor.vendor_num
ORDER BY part.part_num
如果不建立索引，上述查詢代碼的開銷將十分巨大。為此，我們在零件號和廠商號上建立索引。索引的建立避免了在嵌套中反復掃描。關於表與索引的統計信息如下：
表?????行尺寸???行數量?????每頁行數量???數據頁數量
（table）?(row size)?（Row count）?（Rows/Pages）?（Data Pages）
part????150?????10，000????25???????400
Vendor???150?????1，000???? 25???????40
Parven???13????? 15，000????300?????? 50
索引?????鍵尺寸???每頁鍵數量???頁面數量
（Indexes）?(Key Size)?（Keys/Page)???(Leaf Pages）
part?????4??????500???????20
Vendor????4??????500???????2
Parven????8??????250???????60
看起來是個相對簡單的3表連接，但是其查詢開銷是很大的。通過查看系統表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理順序存放的。parven表沒有特定的存放次序。這些表的大小說明從緩沖頁中非順序存取的成功率很小。此語句的優化查詢規劃是：首先從part中順序讀取400頁，然後再對parven表非順序存取1萬次，每次2頁（一個索引頁、一個數據頁），總計2萬個磁碟頁，最後對vendor表非順序存取1.5萬次，合3萬個磁碟頁。可以看出在這個索引好的連接上花費的磁碟存取為5.04萬次。
3. Oracle資料庫大數據量表如何優化
要看數據多到何種程度。
比如一個表的筆數只是幾百，如果不需要和其他大表關聯查詢數據，連索引都不用建。
如果是幾十萬級別的表，一般正確建索引就可以。
如果是千萬級別的表，不但要正確建索引，而且要定時手工進行收集統計信息維護，不建議系統自動維護，以免影響使用性能。
如果是億以上級別的表，則可考慮按一定條件拆分表資拆好租料，將舊資料歸檔，這樣可改旅兆善生成表的使用。
資料庫優化的同時，程序也要襪盯進行相應優化，程序和
數據科學
搭配，才能使性能達到最佳。
4. PHP-大數據量怎麼處理優化
大數據的話可以進行以下操作：
減少對資料庫的讀取，也就是減少調用資料庫，
進行數據緩存，
利用資料庫的自身優化技術，如索引等
精確查詢條件，有利於提高查找速度
5. Oracle等資料庫數據量特別大的時候怎樣從程序和SQL語句方面優化使查詢速度加快
一般最抄常用的大數據量優襲化：
1、創建分區表，使查詢時的大表盡量分割成小表。Oracle提供范圍分區、列表分區、Hash分區以及復合分區，具體選擇哪種分區最優，需要根據你的業務數據來確定。
2、創建索引，創建合適的索引可以大大提高查詢速度。但是你的這張大表如果會頻繁的進行update、insert等操作，索引會導致這些操作變慢。就有可能需要進行動態索引的使用。
3、優化復雜SQL；對復雜的SQL進行合理的優化，這個有時候也需要根據你的數據情況來優化，可以參考一些SQL語句優化方面的文檔。
6. 大數據量實時統計排序分頁查詢 優化總結
大數據量實時統計排序分頁查詢 (並發數較小時) 的瓶頸不是函數（count，sum等）執行，
不是having, 也不是order by，甚至不是表join, 導致慢的原因就在於「數據量太大本身」
就是將表劃分為M份相互獨立的部分,可以是分表，也可以是不分表但冗餘一個取模結果欄位
實際結果是不分表比分表更加靈活，只需稍加配置，就可以動態切分大表，隨意更改M的大小。
將1條慢sql（大於30秒）拆分成為N條查詢速度巨快的sql(單條sql執行時間控制在20毫秒以內)
然後再web應用中以適當的線程數去並發查詢這些執行時間快的N條小sql再匯總結果
第一步查詢中去並發執行這N條小sql, 只取排序欄位和標識欄位，其他欄位一律丟棄
匯總結果後定位出當前頁面要顯示的pageNum條數據，再進行第二步查詢，取出頁面上需要展示的所有欄位
PS：這一點是至關重要的，其他幾點都可以不看，這點是最關鍵的。慢慢解釋一下：
a) 第一種方式是把資料庫中所有記錄（只取排序欄位和標識欄位並且不做任何sum，count having order by等操作）
全部拉到web應用中，在web應用中完成所有的計算
b) 第二種方式是把資料庫中所有記錄做sum count having等操作之後的所有行數拉到web應用中，在web應用中完成剩餘計算
c) 第三種方式是把資料庫中所有記錄做sum count having order by等操作之後把limit後的數據拉到web應用中，
在web應用中對limit後的數據再計算
顯然，第一種方式 資料庫什麼活都不做只取數據 是不可行的。以lg_order_count_seller為例，1500萬行，
如果只算id, seller_id和order_count 這三個bigint類型，至少需要拉8*3*1500 0000 = 360000000=340M,
拉到內存中之後存儲需要8*4*15000000= 460M,這還不算List是的2的n次方這個特點和計算排序等的內存開銷，
不僅資料庫與web應用機器IO扛不住，就是應用自身恐怕也要OOM了。
第二種方式，所有記錄做sum count having等操作之後,由於是group by seller_id的，總得數據量變為100萬（就是賣家總數），
這樣子一來，共需要拉8*3*100 0000 = 23M,拉到內存之後，需要8*4*100 0000 = 30M, 再算上List是的2的n次方這個特點和
計算排序等的內存開銷也不會超過100M, IO的時間和內存開銷勉強可以考慮接受。
第三種方式，所有記錄做sum count having order by等操作之後把limit後的數據拉到web應用中，因為做了limit，所以，
數據量很小了，無論是IO還是內存開銷都已經很小了。可以忽略。
綜合以上三種，第三種方式適用於頁面的前n頁和後n頁，因為這個limit的數據量隨著頁數的增大而增大，
當大到每個切分後的小表的數據量時就轉為第二種方式了。
第二種方式適用於頁面的第[n+1, totaoPageNum-n]頁。
切分成N條小sql後並行執行時排序不穩定性的解決辦法
① 問題描述：
優化之前，還是是一條大慢sql查詢時，由於資料庫排序是穩定排序，
所以當兩條記錄排序欄位值相同時他們在頁面上的頁碼位置是固定的。
優化之後，當並行執行這N條小sql時，由於無法控制這些小sql的先後執行順序，
導致在web應用中當兩條記錄的排序欄位值相同時在頁面上的頁碼位置是隨機的。
② 解決辦法：
除了拉標識欄位(seller_id)和排序欄位(order_count_sum)之外，再取一個unique（id）的欄位，當兩條記錄的排序欄位值相同時，再用這個unique的欄位（在賣家監控中這個欄位是id）進行第二次排序.這樣就解決了排序不穩定的問題。
③ 也許，看到這里會有疑問，為什麼不用seller_id？seller_id也是唯一， 這樣子不是少取id這個欄位，減少IO了？
seller_id雖然也是唯一，可以輔助排序，但是不要忘記資料庫的排序規則是：
如果兩列的值相等，那麼序號在前的排在前面，這里的序號就是主鍵(自動生成，autoincrement),
如果用seller_id的話還是不能保證排序的穩定性，只能用主鍵id.
優先載入頁面上的主要元素，然後再去非同步載入次要元素，
反應在賣家監控頁面中，查數據和查頁頁碼的sql語句基本相同，是在競爭同一資源，
所以，需要做一個策略，優先把資源讓給查數，數據查完之後再去查頁碼。
限流
由於多線程取數據並沒有從本質上提高資料庫性能，所以必須針對大數據量實時統計排序分頁查詢做限流
我這里打個比方：食堂有6個窗口，物流團隊吃飯要買6個菜，平均每買1個菜需要1分鍾的時間，
如果派我一個人去一個窗口買的話需要6分鍾的時間
假如派6個人分別去6個窗口買這6個菜，只需要1分鍾的時間
但是，如果除了物流團隊，再來其他5個團隊呢，也就是說6個團隊每個團隊買6個菜共買36個菜，
這樣子有的團隊先買完，有的團隊後買完，但平均時間還是6分鍾。本質上沒有變化。
所以，對於特定的查詢條件，必須進行限流。讓每分鍾至多有6個團隊買菜，這樣子能使得情況變得不至於太糟糕。
從根本上改變現狀
這一點從目前來看只能是展望了，比如mysql資料庫換更為強大的oracle資料庫，
或更換InnoDb引擎為其他，或更換SATA硬碟為SSD 。。。。。。
從實踐效果來看，優化後的效果是很明顯的。
相同的查詢條件，原來一個頁面查詢時間由於超過60秒超時了，根據1-6點建議優化之後，查詢時間變為2秒至3.5秒之間。
7. ES大數據量下的查詢優化
filesystem類似於我們在mysql上建立一層redis緩存；
es的搜索引擎嚴重依賴於底層的filesystem cache，如果給filesystem cache更多的內存，盡量讓內存可以容納所有的indx segment file索引數據文件，那麼你搜索的時候就基本都是走內存的，性能會非常高。
兩者差距非常大，走磁碟和走systenfile cache的讀取的性能差距可以說是秒級和毫秒級的差距了；
要讓es性能要好，最佳的情況下，就是我們的機器的內存，至少可以容納你的數據量的一半
最佳的情況下，是僅僅在es中就存少量的數據，存儲要用來搜索的那些索引，內存留給filesystem cache的，如果就100G，那麼你就控制數據量在100gb以內，相當於是，你的數據幾乎全部走內存來搜索，性能非常之高，一般可以在1秒以內
的少數幾個欄位就可以了，比如說，就寫入es id name age三個欄位就可以了，然後你可以把其他的欄位數據存在mysql裡面，我們一般是建議用 es + hbase 的一個架構。
hbase的特點是適用於海量數據的在線存儲，就是對hbase可以寫入海量數據，不要做復雜的搜索，就是做很簡單的一些根據id或者范圍進行查詢的這么一個操作就可以了
如果確實內存不足，但是我們又存儲了比較多的數據，比如只有30g給systemfile cache，但是存儲了60g數據情況，這種情況可以做數據預熱；
我們可以將一些高頻訪問的熱點數據（比如微博知乎的熱榜榜單數據，電商的熱門商品（旗艦版手機，榜單商品信息）等等）提前預熱，定期訪問刷到我們es里；（比如定期訪問一下當季蘋果旗艦手機關鍵詞，比如現在的iphone12）
對於那些你覺得比較熱的，經常會有人訪問的數據，最好做一個專門的緩存預熱子系統，就是對熱數據，每隔一段時間，提前訪問一下，讓數據進入filesystem cache裡面去。這樣下次別人訪問的時候，一定性能會好一些。
我們可以將冷數據寫入一個索引中，然後熱數據寫入另外一個索引中，這樣可以確保熱數據在被預熱之後，盡量都讓他們留在filesystem os cache里，別讓冷數據給沖刷掉。
盡量做到設計document的時候就把需要數據結構都做好，這樣搜索的數據寫入的時候就完成。對於一些太復雜的操作，比如join，nested，parent-child搜索都要盡量避免，性能都很差的。
es的分頁是較坑的 ，為啥呢？舉個例子吧，假如你每頁是10條數據，你現在要查詢第100頁，實際上是會把 每個shard上存儲的前1000條數據都查到 一個協調節點上，如果你有個5個shard，那麼就有5000條數據，接著 協調節點對這5000條數據進行一些合並、處理，再獲取到最終第100頁的10條數據。
因為他是分布式的，你要查第100頁的10條數據，你是不可能說從5個shard，每個shard就查2條數據？最後到協調節點合並成10條數據？這樣肯定不行，因為我們從單個結點上拿的數據幾乎不可能正好是所需的數據。我們必須得從每個shard都查1000條數據過來，然後根據你的需求進行排序、篩選等等操作，最後再次分頁，拿到裡面第100頁的數據。
你翻頁的時候，翻的越深，每個shard返回的數據就越多，而且協調節點處理的時間越長。非常坑爹。所以用es做分頁的時候，你會發現越翻到後面，就越是慢。
我們之前也是遇到過這個問題，用es作分頁，前幾頁就幾十毫秒，翻到10頁之後，幾十頁的時候，基本上就要5~10秒才能查出來一頁數據了
你系統不允許他翻那麼深的頁，或者產品同意翻的越深，性能就越差
如果是類似於微博中，下拉刷微博，刷出來一頁一頁的，可以用scroll api
scroll api1 scroll api2
scroll會一次性給你生成所有數據的一個快照，然後每次翻頁就是通過游標移動 ，獲取下一頁下一頁這樣子，性能會比上面說的那種分頁性能也高很多很多
scroll的原理實際上是保留一個數據快照，然後在一定時間內，你如果不斷的滑動往後翻頁的時候，類似於你現在在瀏覽微博，不斷往下刷新翻頁。那麼就用scroll不斷通過游標獲取下一頁數據，這個性能是很高的，比es實際翻頁要好的多的多。
缺點：
8. MySQL大數據量分頁查詢方法及其優化
使用子查詢優化大數據量分頁查詢
這種方式的做法是先定位偏移位置的id，然後再往後查詢，適用於id遞增的情況。
使用id限定優化大數據量分頁查詢
使用這種方式需要先假設數據表的id是連續遞增的，我們根據查詢的頁數和查詢的記錄數可以算出查詢的id的范圍，可以使用 id between and 來查詢：
當然了，也可以使用in的方式來進行查詢，這種方式經常用在多表關聯的情況下，使用其他表查詢的id集合來進行查詢：
但是使用這種in查詢方式的時候要注意的是，某些MySQL版本並不支持在in子句中使用limit子句。
參考 sql優化之大數據量分頁查詢（mysql） - yanggb - 博客園 (cnblogs.com)