MySQL 兩張千萬級數(shù)據(jù)表聯(lián)查如何優(yōu)化？

1.id 主鍵 2.user_id加索引
2.在數(shù)據(jù)表結(jié)構(gòu)優(yōu)化，增加臨時表，專門存儲兩個表的id，并將user. user_name,order.order_number存儲在臨時表內(nèi)

將這兩個表做讀寫分離，專門查的地方啟用數(shù)據(jù)庫緩存，對于訂單表可以做拆分，比如將歷史記錄（范圍可以視業(yè)務(wù)情況而定，一般可以將超過1年的記錄放到歷史記錄表里面），因為數(shù)據(jù)一般都是分頁顯示的，歷史記錄大部分情況用戶不會去關(guān)心，所以跟新紀錄放到一起完全沒有必要，當然這么做需要開發(fā)成本較高，對于用戶表可以根據(jù)userid（假設(shè)userid是自增的）做分區(qū)，按照一定的數(shù)據(jù)量級別（10W）作為一個分區(qū)單元，這樣查詢的時候就把1000W級縮成了10W級

這個sql就很可疑，最簡單的把order作主表join關(guān)聯(lián)user應(yīng)該比現(xiàn)在的sql效率好

SELECT
    `user`. user_name,
    `order`.order_number
FROM
    `order`
JOIN `order` ON`user`.id = `order`.user_id

當然了，單表數(shù)據(jù)上升到1千萬之前，就該采取適當?shù)姆直聿呗?，比如樓?code>gary345的回答

這是一個典型的大表左連接問題。
分析：order表中的數(shù)據(jù)一旦創(chuàng)建修改就很少了，所以可以采取冗余的方式，亦即直接把，order的多個order_number字段放在user表里面（適當?shù)倪`反范式也是可以的，畢竟mysql都可以存json了）。
如果跳出mysql，這本書https://segmentfault.com/a/11...
里面的OceanBase有專門針對這個問題做優(yōu)化，亦即采用冗余+基準數(shù)據(jù)和新改數(shù)據(jù)合并+定期更新基準數(shù)據(jù)的方式。

除了樓上的建索引外，建一張中間表，用來存儲已經(jīng)付費的玩家的id和username，這張表可以提前刷好，當有用戶付費的時候就往里面插入。這樣可以減小user 表的規(guī)模。