試試媒體查詢，或者flex布局，或者bootstrap的網(wǎng)格系統(tǒng)，等等。。。。

• 也許這個(gè)項(xiàng)目有所謂的歷史遺留問題， 先有schema2.order。 再有schema1 。
• 也是是技術(shù)老大想試試mongo的Arrey子集合分頁查詢好不好用。
• 空間換時(shí)間。 數(shù)據(jù)庫輕輕松松破TB。

以上純屬妄言。。

另 : _id直接用做訂單id也可以啊， 本身mongo的_id生成算法是分布式的一種id生成算法。時(shí)間戳+機(jī)器碼+進(jìn)程Id+隨機(jī)數(shù)

分開來一次不要查全部的 比如說你有100W條數(shù)據(jù) 做統(tǒng)計(jì)他也不可能一次看100W條你可以以分頁的形式統(tǒng)計(jì)或者默認(rèn)條件統(tǒng)計(jì)，這樣就不會(huì)超時(shí)啦

命中索引是數(shù)據(jù)庫使用的基本原則。不知道執(zhí)行了什么樣的查詢，這樣沒有辦法幫你優(yōu)化。

這個(gè)子查詢的作用是：

對(duì)于一行數(shù)據(jù)
查找同部門，計(jì)算同部門工資比他高的人的人數(shù)

如果少于三個(gè) (說明他的工資就是該部門前三高)

那么 where 成立

不要直接拼接字符串，如果你的內(nèi)容包括以下符號(hào) ' -- [ ] 等 ，可能會(huì)報(bào)錯(cuò)，
例如本來你想查詢 select * from table where name = '${var1}';， 如果你的變量var1 是 Mr.W'O，那么拼接后你的語句就變成了 select * from table where name = 'Mr.W'O'; 語句中出現(xiàn)了三個(gè) ' 當(dāng)然會(huì)報(bào)語法錯(cuò)誤。 報(bào)錯(cuò)還是小事情，被黑客利用而進(jìn)行sql注入就麻煩了。
建議你用node的模塊mysql或mysql2 對(duì)變量進(jìn)行編碼，可能你的寫法就變成了這樣

var sql = `insert into article_list
          (title,author,summary,is_top,catalog_alias,content)
           values
            (?,?,?,?,?,?)`;
let result = mysql.query(sql, [req.body.title, req.body.author,req.body.summary,req.body.is_top])

這個(gè)沒有特定的規(guī)律，哈哈；

像httpd/mysqld 中的d的含義一般是deamon的意思。

自動(dòng)轉(zhuǎn)換，任何強(qiáng)類型的語言都是這樣的。
C、C++、Java等語言中，(double)的0和(int)的0也是相等的啊。

webView 你可以當(dāng)做一個(gè)瀏覽器就行了，保存文章，直接把頁面上編寫的文章保存到數(shù)據(jù)庫就好了啊。
安卓webView中嵌套你前端寫好的H5頁面并且給你傳文章ID，你拿到文章ID后調(diào)用AJAX請求向后臺(tái)接口中去請求數(shù)據(jù)就好了。你就正常當(dāng)在chrome中開發(fā)。

公司里面的mysql好像有問題，我回家試了一下，沒有發(fā)生這種詭異的事件

傳說有的系統(tǒng)里有一個(gè)專門吃mysql的妖怪，它每隔一段時(shí)間就會(huì)出來覓食，把可憐的mysql找到并吃掉，而且它嗅覺非常靈敏，無論躲到哪里都沒用。當(dāng)它吃飽了，就會(huì)回到巢穴呼呼大睡，只有下一次餓了才會(huì)出來。

由于是天敵，可憐的mysql完全沒有辦法抵抗，甚至連招架之力都沒有。一旦被找到就是必死無疑。它只能寄希望于它的主人，但偏偏它的主人是一個(gè)連問題都不太會(huì)的老實(shí)人，可憐的mysql現(xiàn)在連一點(diǎn)希望都沒有了！

—— 安徒生

查了下文檔，應(yīng)該是因?yàn)槟氵@是兩次查詢，一次count查詢，一次skip加limit查詢，所以你的query查詢永遠(yuǎn)都是最先指定的count查詢，所以你第二次的結(jié)果其實(shí)就是count返回的結(jié)果，所以是number類型的數(shù)字。

雖然不知道你為啥又不寫回調(diào)，又不走Promise形式也能得到結(jié)果。我也就這么寫了~

分兩次查詢就行了，因?yàn)槟愕诙尾樵兪莝kip加limit，所以應(yīng)該沒辦法不走2次查詢又能得出總文檔數(shù)又能得出分頁查詢得結(jié)果。

const query1 = myModel.find({name:'xiaoming'});
const query2 = myModel.find({name:'xiaoming'});
const total = await query1.count().exec(); //所有name為xiaoming的文檔數(shù)量
const data = await query2.skip(20).limit(10).exec();

一天 300W ，一周 2000W ，一個(gè)月 1億，一年是 10 億級(jí)別的，還是算大了。（當(dāng)然，如果你的指標(biāo)維度，只有你列出的那么一點(diǎn)，那數(shù)據(jù)還是很簡單的）
MySQL 就別想了，不光它，任何通用的關(guān)系型數(shù)據(jù)庫都別想了。
并且，通用數(shù)據(jù)模型層面的（即指望一套方案，在不人為針對(duì)性設(shè)計(jì)的情況下，直接解決所有數(shù)據(jù)存儲(chǔ)的問題），就不要想著去解決了。（真不是你們能解決的問題）
針對(duì)具體“事實(shí)”下的數(shù)據(jù)，專門做一些存儲(chǔ)的設(shè)計(jì)，要解決還是有可能的。

功能好點(diǎn)的方案，我知道有 2 個(gè)，一個(gè)是基于 Postgresql 的 Greenplum ，另一個(gè)是 yandex 開源出來的 Clickhouse。

前段時(shí)間我看 ClickHouse 的東西寫在 https://www.zouyesheng.com/cl... 。

另外還有一個(gè)思路，就是靠 HBase 這種，窮舉維度預(yù)處理計(jì)算，靠空間換時(shí)間。不過這種方案，在應(yīng)用層上不太好設(shè)計(jì)，對(duì) SQL 的基本支持都是一個(gè)挑戰(zhàn)。

既然選擇orm框架，就應(yīng)該使用數(shù)據(jù)模型來綁定關(guān)聯(lián)。
sequelize模型支持1對(duì)1，1對(duì)多，多對(duì)多關(guān)聯(lián)。
如果單純想使用sql語句，就應(yīng)該放棄sequelize，畢竟orm的特性是模型

原本是建議用ref操作的，不過看到你是用v-html這個(gè)方案就不可行了，不知道你的html是后端提供的還是自己拼接的，如果可以在img上面直接加一個(gè)方法就能很簡單的實(shí)現(xiàn)你的需求了。

data() {
  return {
    html: '<img src="xxx" onload="onImgLoad(this)">',
  }
},

在vm外面定義一個(gè)全局函數(shù)來處理

window.onImgLoad = (el) => {
  if (el.width > 630) {
    el.style.width = '100%'
  }
}

exists

指定一個(gè)子查詢，檢測行的存在。遍歷循環(huán)外表，然后看外表中的記錄有沒有和內(nèi)表的數(shù)據(jù)一樣的。匹配上就將結(jié)果放入結(jié)果集中。具體sql語句如下：

SELECT
    `user`.*
FROM
    `user`
WHERE
    EXISTS (
        SELECT
            `order`.user_id
        FROM
            `order`
        WHERE
            `user`.id = `order`.user_id
    )

使用exists關(guān)鍵字進(jìn)行查詢的時(shí)候，首先，我們先查詢的不是子查詢的內(nèi)容，而是查我們的主查詢的表，也就是說，我們先執(zhí)行的sql語句是：

SELECT `user`.* FROM `user` 

然后，根據(jù)表的每一條記錄，執(zhí)行以下語句，依次去判斷where后面的條件是否成立：

EXISTS (
        SELECT
            `order`.user_id
        FROM
            `order`
        WHERE
            `user`.id = `order`.user_id
    )

如果成立則返回true不成立則返回false。如果返回的是true的話，則該行結(jié)果保留，如果返回的是false的話，則刪除該行，最后將得到的結(jié)果返回。也可以和IN對(duì)比來分辯認(rèn)識(shí)它們
Sql語句中IN和exists的區(qū)別及應(yīng)用

postgre, 一對(duì)多用數(shù)組

WITH C AS (SELECT 商品ID,ARRAY_AGG(標(biāo)簽) AS 標(biāo)簽 FROM B GROUP BY 商品ID)
SELECT A.*, 標(biāo)簽 FROM A LEFT JOIN C USING(商品ID) WHERE 你的條件

我提個(gè)曲線救國的方法，就別按userid分表了，怪累的，直接根據(jù)評(píng)論時(shí)間按月分表，我們的經(jīng)驗(yàn)是Mysql的話每張表不超過2000萬條數(shù)據(jù)就行，這樣匯總起來就方便多了，后臺(tái)管理唯一需要注意的就是pagination的問題。

就算是拋磚引玉了，希望能幫到你。

更新：flc1125提到了負(fù)載的問題，我頂多能想到加redis緩存，還想問問這個(gè)評(píng)論的主要查詢業(yè)務(wù)是啥？是展示某個(gè)文章的最近評(píng)論？

很有可能是你這幾條數(shù)據(jù)已經(jīng)被刪除了

但是沒有刷新數(shù)據(jù)庫

導(dǎo)致拋出刪除已經(jīng)不存在的數(shù)據(jù)

刷新一下試試