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

因?yàn)?getRealPath 是返回物理邏輯路徑，參考getRealPath)；

你可能應(yīng)該用這個(gè)：getContextPath)

咳咳，我大致理解下你的這個(gè)表關(guān)系，即 R1 是同屬級(jí)，同屬級(jí)之間進(jìn)行連接。但如果出現(xiàn)用戶 N6 即同屬 R1 級(jí)別又同屬 R2 級(jí)別，則連接，并且 N6 所屬的 R1 級(jí)別以及 R2 級(jí)別的所有成員也都互相成為連接關(guān)系？

varchar類型排序和字符串排序一樣，先從第一位的開始比較，8,7,6,5,4,3,2,1，0這種數(shù)據(jù)，如果第一位相同比較第二位......可以考慮排序的時(shí)候轉(zhuǎn)換一下，或者表數(shù)據(jù)設(shè)計(jì)成decimal類型

https://dev.mysql.com/doc/ref...

MySQL converts TIMESTAMP values from the current time zone to UTC for storage, and back from UTC to the current time zone for retrieval. 

TIMESTAMP 類型的這種轉(zhuǎn)換操作，相較于 INT，可能使查詢變慢。

在PG中，數(shù)據(jù)是tuple組織的，每個(gè)tuple都是固定的storage layout，即字段存儲(chǔ)的物理順序是固定的，解釋時(shí)是按照pg_attribute中存儲(chǔ)的順序。

PostgreSQL的字段順序不能直接使用SQL進(jìn)行修改。但是可以間接操作，使用臨時(shí)表，將數(shù)據(jù)導(dǎo)入，然后再將數(shù)據(jù)統(tǒng)一插入原有表。

首先你得確認(rèn)是不是mysql問題，找個(gè)其他的客戶端連一下mysql看看有沒有問題，正常的話就是你這Navicat的問題了，重裝吧。。 另外，Navicat綠色版不少啊，去下啊。。

系統(tǒng)記錄錯(cuò)誤日志的功能是關(guān)閉的, 錯(cuò)誤信息被輸出到標(biāo)準(zhǔn)錯(cuò)誤輸出stderr,開啟了之后才會(huì)有.err錯(cuò)誤文件。

可能原因：

1. 訪問的文件確實(shí)不存在。
2. nginx的配置文件中的訪問項(xiàng)目的路徑地址與你實(shí)際的項(xiàng)目地址不同。

解決思路：
從報(bào)錯(cuò)404 Page Not Found著手，確認(rèn)上述原因。

借樓上的兩張表一用，sql可以采取左連接：

select 
    u.phone,
    r.createdAt
from
    user u
    left join recharges r on u.phone = r.phone
where
    u.phone = ''
    and r.createdAt in (
        select max(createdAt) from recharges
    )
group by u.phone

類似于這種思路，不過那個(gè)sql的in性能不是很好，這里可以再稍微優(yōu)化下

保證對(duì)應(yīng)文檔存在，以及不怕getMoney重復(fù)的話，可以這么寫：

YOUR_MODEL.update(
  { name: "gaomin" },
  { $push: { getMoney: { money: a } } },
  (err, raw) => {
    if (err) throw err
    console.log(raw)
  }
)

下載卡死，主要還是要分析下SQL是否合理。如果是SQL計(jì)算導(dǎo)致了mySQL CPU占用100%，那么就應(yīng)該修正SQL，建立索引。

1. 分散存儲(chǔ)可以減少表連接，加快查詢速度
2. 集中存儲(chǔ)的話可以做到查看所有上傳的圖片附件，一般做項(xiàng)目文檔管理用的比較多（也可以做附件版本），缺點(diǎn)是需要連表

因?yàn)槟愕?code>getData方法不是在你自定義組件上觸發(fā)的，你把這個(gè)方法寫在ion-content上當(dāng)然不可以啦。

兩種都可存儲(chǔ)，但是MongoDB比較適合用在日志、股票系統(tǒng)。不支持多表查詢、不支持事物邏輯復(fù)雜。就相當(dāng)于當(dāng)一個(gè)數(shù)據(jù)的倉(cāng)庫(kù)來使用吧。根據(jù)自己系統(tǒng)需求性來選擇，建議使用mysql更為合適。

webpack.dll.config.js中設(shè)置resolve.modules,指定模塊掃描目錄

沒明白時(shí)區(qū)隨機(jī)是什么意思，從頭部和尾部的updatedAt/createAt看來你設(shè)置時(shí)區(qū)已經(jīng)成功了。

SELECT b.rank,c.score FROM (
SELECT count(*)+1 as 'rank' FROM (
SELECT id,u.score FROM 學(xué)生表 i LEFT JOIN (
SELECT id,SUM(score)as score FROM 成績(jī)表 GROUP BY id
)u ON u.id=i.id ORDER BY u.score DESC
) a WHERE a.score>(SELECT sum(score) FROM 成績(jī)表 WHERE id=1)
) b
LEFT JOIN (
SELECT sum(score)as score FROM 成績(jī)表 WHERE id=1
) c on 1=1

應(yīng)該是可以一步到位的，試一試

數(shù)據(jù)提取出來后，這就是純統(tǒng)計(jì)算法問題了，跟是否前后端無(wú)關(guān)，當(dāng)然實(shí)現(xiàn)起來也是比較簡(jiǎn)單

const list = [
  {"id": 1, "name": "one", "tags": ["a", "c", "e"]},
  {"id": 2, "name": "two", "tags": ["e"]},
  {"id": 3, "name": "three", "tags": ["d", "e"]},
  {"id": 4, "name": "four", "tags": ["g", "c", "e", "h"]},
  {"id": 5, "name": "five", "tags": ["a", "c", "d"]}
];
const result = {
  length: 0 //不同的標(biāo)簽類型個(gè)數(shù)
};
list.forEach(item => {
  item.tags.forEach(tag => {
    if (!result[tag]) {
      result[tag] = {
        name: tag,  //標(biāo)簽名
        list: []    //包含含有此標(biāo)簽的id 數(shù)組length就是此標(biāo)簽下的條目數(shù)
      };
      result.length += 1;
    }
    result[tag].list.push(item.id);
  })
});
console.log(result)

已解決，是我沒搞清楚路由映射的原理。直接用域名/polls/正則即可訪問。謝謝大家！