肯定是落地于 db，不然 如何持久化。那是你rmb 換來的啊，存在內存中電腦斷電不就好玩了
只不過 充值啊，消耗積分這些不一定在你每次 操作之后 就存儲 在 DB 中
可能利用其他技術 延遲放入 數(shù)據庫中，只要保證 數(shù)據庫最終一致性 就可以了

MySQL的索引主要指的是BTree索引，需要遵循最左前綴原則，常規(guī)的做法會根據select語句對索引進行定制，像這種后臺管理的場景，sql基本是拼接的，可以說沒有固定索引，這種情況，可以使用以下方案進行優(yōu)化：

1. 暫時不建索引，把MySQL的慢查詢打開，對系統(tǒng)中的慢查詢進行統(tǒng)計分析，然后有針對性的進行索引優(yōu)化
2. 使用MySQL主從架構，在從庫上進行查詢，系統(tǒng)會慢，但保證不對主庫造成影響
3. 放棄MySQL，使用搜索引擎技術，及基于lucene的Solr或es

select * from table_1 RIGHT JOIN table_2 ON table_1.id = table_2.uid
where table_1.status = 1 AND table_2.level_id = 1 AND table_2.level_id = 2

這段代碼意思是同一條table2的記錄同時是等級1和等級2，是個假命題。。
改的話需要right join兩次table2

select table_1.* from table_1 
RIGHT JOIN table_2 t2Lv1 ON table_1.id = t2Lv1.uid ON t2Lv1.level_id = 1
RIGHT JOIN table_2 t2Lv2 ON table_1.id = t2Lv2.uid ON t2Lv2.level_id = 2
where table_1.status = 1
GROUP BY table_1.id

大致思路就是這樣

https://www.cnblogs.com/usual...

你的this，在渲染的時候，已經丟失了吧……這里也許在click的時候應該使用箭頭函數(shù)才能把this帶過去

有可能是并發(fā)或者鎖表，語句主要集中在 1~2 分鐘之內

完全沒必要啊，直接用腳本調用mongodump + mongorestore不就搞定的事情？何必寫一個python程序？

mysql5.7支持json

你們公司有 DBA 嗎，沒有的話分庫分表堆機器用錢砸。

這取決于你所選擇的引擎和文件系統(tǒng)。

MyISAM 在 MySQL 5.0 之后單表上限取決于文件系統(tǒng)。
Innodb 在 共享表空間存儲方式 的情況下單表上限（不是單文件）為 64TB 左右，其中包含索引等相關數(shù)據；
在 獨享表空間存儲方式 的情況下單表上限由文件系統(tǒng)決定。

以上相關信息由百度結果 mysql單表大小的限制 - CSDN （該文發(fā)布于 2015年01月18日） 得來，關鍵字為 MySQL 單表上限，最新的數(shù)據應以官網為準。

加粗文字

加粗文字

列表項目

最大的有符號 BIGINT值是9223372036854775807,檢查一下有沒有溢出
參考官方問題解釋

https://dev.mysql.com/doc/refman/8.0/en/out-of-range-and-overflow.html

間隔2天的寫法：

SELECT * FROM `dates` WHERE DATEDIFF(`date`, '2018-01-01') % 2 = 0;

前30天的應該自己會寫了吧 ^_^

select * from table order by TIME desc

首先作為畢設 , 我感覺這個表設計本身沒啥硬傷 .
其次是 , 百度云是用的mongodb , 一次mongodb的分享會上聽過百度云的人分享過一些技術 .

關于MongoDB
首先是警告不是錯誤，并不會造成你不能運行；
其次警告的內容是不是自己先理解一下，看看有什么不懂的地方？

關于NodeJS
可能要說英文不好，那我們來一個詞一個詞讀讀

app crashed - waiting for file changes before starting...
應用崩潰了 - 等待文件變更 在重啟之前...

意思是不是很明白？由于某種錯誤應用不能成功啟動，那么現(xiàn)在能重試嗎？不管怎么重試還是會失敗對不對？所以nodemon要等待文件有變更后再重試是不是更有道理一些呢？
那到底是什么問題？看日志啊，沒有日志鬼知道什么問題。

無關的話：建議樓主看到一大堆英文就算很崩潰還是讀一下，并沒有你想象的那么難。永遠不讀就永遠不會懂，讀一讀，慢慢就越來越容易。

給guid字段添加普通索引

這是我測試數(shù)據：

加索引id執(zhí)行計劃：

explain SELECT * FROM qxd.qxd_community where id = '540a1cb9-04cc-ce17-9933-81bb115328bb'

未加索引id執(zhí)行計劃：

mycat 慎用 感覺領導者在搞傳銷一樣 加群你就知道了 天天做培訓 問個問題 都要紅包

僅從MongoDB的角度說明這種東西可以怎么存。至于別人到底是怎么存，我們是不知道的。

關系模型存法

不多介紹，可以按照范式設計成跟關系數(shù)據庫一樣的表結構來存儲，大概是：

{
    _id: ObjectId(...),
    comment: "...",
    time: ISODate(...),
    user: "...",
    musicId: "...",
    ...
}

如果用慣關系數(shù)據庫的用戶，這樣的做法簡單自然。在現(xiàn)在討論的場景下，這樣沒有太大的問題，在數(shù)據量大時可以使用分片來達到水平擴展以應對數(shù)據量的增長。
不過仍有可以改進的地方。這要從MongoDB的模型設計來講起。簡單地說，MongoDB是實用主義，怎么方便怎么來，怎么快怎么來，完全不應該受范式的約束。但這也意味著你的模型要從應用的需求出發(fā)。僅從上面截圖的信息，可能有2個不同的需求：

1. 評論
2. 點贊

考慮到評論和點贊都有可能上萬甚至上十萬百萬，它們以單獨的集合來存放會比較合適。但是為了讀取和存儲效率，我會考慮把多條評論壓縮到一起，這種方式通常稱為分桶(bucket)。

非關系模型存法

{
    _id: ObjectId(...),
    musicId: "...",
    // 根據需要可能將音樂本身的一些數(shù)據冗余進來
    musicName: "...",
    comments: [
        {content: "...", time: ISODate(...), user: "..."},
        {content: "...", time: ISODate(...), user: "..."},
        {content: "...", time: ISODate(...), user: "..."},
        ...
    ],
    count: 10, // 該桶內已有10條comments
}

comments的數(shù)據量我會考慮一頁會展示多少評論（比如30條），那么在添加評論時可以有：

db.comments.updateOne({
    musicId: "...",
    count: {$lt: 30}
}, {
    $push: {
        comments: {content: "...", time: ISODate(...), user: "..."}
    },
    $inc: { count: 1 }
}, {
    upsert: true
});
// 優(yōu)化查詢速度會使用到索引：
db.comments.createIndex({
    musicId: 1,
    count: 1
});

在查詢時總是只需要最多取最新的2條記錄就可以查到第一頁：

db.comments.find({
    musicId: "..."
}).sort({_id: -1}).limit(2)
// 這個查詢需要索引
db.comments.createIndex({
    musicId: 1,
    _id: -1
});

注意_id的高4位是時間，所以是可以排序的，其順序就是時間順序。
點贊的問題可以通過類似的方式實現(xiàn)，就留給你自己思考了。

可以的。
微信授權之后拿到openid，檢測openid是不是在系統(tǒng)中，如果在，就用openid登錄，完了返回token。
如果沒在系統(tǒng)中，那么插入新用戶之后再返回tokken