鍍金池/ 問答/ 數(shù)據(jù)庫問答
北城荒 回答

href="?q=swbx111111&page... 其中swbx111111用字符串拼接的方式拼上

舉個(gè)例子：

render(request, 'device.html', {'contacts': contacts, 'q': q})

所有的href加上q

href = "?page={{ page }} & q={{ q }}"
風(fēng)畔 回答 
SELECT cls.id AS lesson_id,
   c.id AS course_id,
   cl.id AS course_level_id,
   cu.id AS course_unit_id
FROM course c 
INNER JOIN course_level cl 
  ON c.id = cl.course_id
INNER JOIN course_unit cu
  ON c.id = cu.course_id
    AND cl.id = cu.course_level_id
INNER JOIN course_lesson cls
  ON c.id = cls.course_id
    AND cl.id = cls.course_level_id
    AND cu.id = cls.course_unit_id
ORDER BY c.sort, c.id, 
    cl.sort, cl.id, 
    cu.sort, cu.id,
    cls.sort, cls.id
維她命 回答

要這樣理解，你給的排序條件是不充分的。數(shù)據(jù)庫已經(jīng)按照你的要求按{count: -1}完成了排序，但是因?yàn)樗鼈兊闹刀家粯樱还苷l放在前面誰放在后面其實(shí)都沒有違反你的要求，因?yàn)槟愕囊笾皇莄ount的降序而已。從數(shù)據(jù)庫的角度來講，既然你沒有額外的要求，那當(dāng)然是以最高效的方式給你結(jié)果，也就是不管count以外的順序，因?yàn)檫@樣最省資源。
那么何為最高效？這里涉及一些數(shù)據(jù)庫底層的知識(shí)。在單機(jī)上，如果沒有索引支持，數(shù)據(jù)庫會(huì)嘗試遍歷所有數(shù)據(jù)，然后做一個(gè)內(nèi)存排序來給你結(jié)果，從節(jié)省資源的角度，顯然這個(gè)排序只排到滿足了count降序?yàn)橹梗渌侄慰梢哉f是先到先得。這就造成在count相同時(shí)，其他順序是隨機(jī)的。它們可能受到：

  1. 自己在磁盤上的順序影響，因?yàn)檫@會(huì)影響到數(shù)據(jù)庫先遍歷到哪條記錄。并且要注意，每次更新數(shù)據(jù)時(shí)它們?cè)诖疟P上的順序是會(huì)變化的；
  2. 理論上還和數(shù)據(jù)庫使用的排序算法相關(guān)。很遺憾我也沒有關(guān)注這里的排序到底使用什么算法，沒法給你進(jìn)一步的信息；
  3. 在分片集群環(huán)境中，結(jié)果還受到哪個(gè)片先返回?cái)?shù)據(jù)的影響。分片環(huán)境中的排序是先在各個(gè)片排好序，再進(jìn)行一次合并排序；

暫時(shí)想到這些?？傊?，你不指定，數(shù)據(jù)庫不保證。
至于解決方案也已經(jīng)很明了了，指定一個(gè)可以完全確定順序的排序條件，比如：

{$sort: {count: -1, _id: 1}}

但是需要理解，這樣會(huì)讓數(shù)據(jù)庫付出額外的努力來保證第二個(gè)排序條件的正確性，在實(shí)際使用場(chǎng)景中你要根據(jù)實(shí)際情況判斷這是不是真的對(duì)你有意義。

最后說句無關(guān)的話，以后提問的時(shí)候建議盡可能用文本貼出相關(guān)的代碼和結(jié)果，而不是截圖。因?yàn)榻貓D雖然方便了你自己，別人在回答問題的時(shí)候如果想用你的代碼或者數(shù)據(jù)做實(shí)驗(yàn)?zāi)蔷拖喈?dāng)麻煩。沒有耐心的人可能直接忽略你的問題，對(duì)你尋找答案也不是件好事。

心夠野 回答

base應(yīng)該是這個(gè)索引的名字吧，KEY base (xxx, yyy)跟KEY (xxx, yyy)效果應(yīng)該是一樣的。

但不清楚既然有了PK (xxx, yyy, zzz)，要KEY (xxx, yyy)還有什么用。

挽歌 回答 
> db.a.find({},{stories:1,_id:0})
{ "stories" : [ { "images" : "1.jpg", "title" : "標(biāo)題1" }, { "images" : "2.jpg",
 "title" : "標(biāo)題2" }, { "images" : "3.jpg", "title" : "標(biāo)題3" } ] }

> db.a.update({},{$push:{stories:{"images": "4.jpg","title": "標(biāo)題4"}}})

圖片描述

圖片描述

涼汐 回答

你說的是建表的字段么？我是在跨境電商公司上班，分享一下公司的商品表中的基本字段。
sku，商品的唯一標(biāo)識(shí)，如一件白色的T恤
spu，同款sku的組合，如同款的T恤，有白色，藍(lán)色，黃色，紅色等
scu，多個(gè)sku的組合，如上衣和褲子一起賣
scpu，同款scu的組合，
price，長(zhǎng)描述，短描述（買點(diǎn)），可用庫存，倉庫號(hào)，銷售員，采購員，商品類名，商品圖片，
商品狀態(tài)（上架，下架，待發(fā)貨，待顧客反饋，待質(zhì)檢，等等一大堆）
還有好多，，，，數(shù)據(jù)庫用的是Mongodb，淘寶好像用的是Mysql，用的是他們自己家開發(fā)的Druid 鏈接數(shù)據(jù)庫。
所有表都應(yīng)該有的，id，創(chuàng)建時(shí)間，更新時(shí)間，就不多說了。

不討喜 回答

官網(wǎng)：MySQL :: MySQL 5.5 Reference Manual :: C.10.4 Limits on Table Column Count and Row Size: https://dev.mysql.com/doc/ref...

MySQL has hard limit of 4096 columns per table, but the effective maximum may be less for a given table. The exact column limit depends on several factors:

還有，如果都考慮列數(shù)極限了，那么就要思考一下設(shè)計(jì)是不是有問題了

乖乖瀦 回答

這個(gè)問題跟MongoDB相關(guān)是體現(xiàn)在想用MongoDB存儲(chǔ)這些文檔的內(nèi)容？還是說只是想用MongoDB管理這些文檔的版本？
這個(gè)問題要展開了說挺復(fù)雜的，想想Google Docs或者Office 365（老板是給你開了多少錢要做這么復(fù)雜的應(yīng)用？）。簡(jiǎn)單地實(shí)現(xiàn)也可以，就是把每個(gè)版本的word文檔都存下來就好了，每個(gè)標(biāo)上版本號(hào)。

孤星 回答

先獲取數(shù)據(jù)總個(gè)數(shù) select count(*) as sum from User
總頁數(shù) pages = Math.ceil(sum/n) //每頁顯示n個(gè)
再根據(jù)頁數(shù)去查詢 select * from User limit index,n //index 頁碼

愿如初 回答

因?yàn)槟愕膇nsert語句寫得不對(duì)

insert into user2 select i.u_id, i.u_name, i.u_age, i.u_schoolid from user1;

你這樣寫，等同于把i插了N遍，N為user1的記錄數(shù)。
而且你外層又循環(huán)了N遍，結(jié)果就是你把user1表的每條記錄都插了8遍

你要這么寫才是對(duì)的：

insert into user2 select i.u_id, i.u_name, i.u_age, i.u_schoolid from dual;

要不就正常點(diǎn)，既然你是一行一行的讀，那你就一行一行的插

insert into user2 (u_id,u_name,u_age,u_schoolid)
values(i.u_id, i.u_name, i.u_age, i.u_schoolid);
陌璃 回答

可以利用 html5 的 download 屬性

<a  href="demo.jpg" download="demo.jpg">下載</a>
落殤 回答
而連接池大小的配置是在單一服務(wù)上配置
在 N 個(gè)服務(wù)訪問這個(gè) mysql 機(jī)器的情況下
加入每個(gè)服務(wù)的配置都是上述公式
那么總的連接池?cái)?shù)就是 N((核心數(shù) 2) + 有效磁盤數(shù))了
這不是悖論嗎？
如何理解？

沒有什么悖論呀。舉個(gè)例子，比如一個(gè)mysql支持的并發(fā)連接最多100個(gè)，你有3個(gè)微服務(wù)應(yīng)用需要同時(shí)連接這個(gè)數(shù)據(jù)庫，每個(gè)微服務(wù)部署在一臺(tái)獨(dú)立的機(jī)器上，每個(gè)機(jī)器核心數(shù)為8，磁盤數(shù)為2。 3 (2 8 + 2) 遠(yuǎn)遠(yuǎn)小于100呀。

即使超過的mysql可以支持最大并發(fā)數(shù)，可以稍減少某些微服務(wù)的連接池連接數(shù)，沒有說連接池中的連接數(shù)必須是(核心數(shù) * 2) + 有效磁盤數(shù)。

其次，配置監(jiān)控系統(tǒng) Servlet 也是在單個(gè)服務(wù)下配置
而訪問 url 諸如這種
http://IP:PORT/druid
那 N 個(gè)微服務(wù)豈不是會(huì)有 N 個(gè)配置監(jiān)控系統(tǒng) Servlet?
假如有幾個(gè)微服務(wù)處于同一臺(tái)機(jī)器上
那就還要配置不同的 url
這樣感覺怪怪的？

不奇怪呀，不同的微服務(wù)只需要關(guān)注自己的druid的監(jiān)控。如果需要總的監(jiān)控信息，mysql 提供了很多狀態(tài)變量，相關(guān)日志（比例慢查日期）等，當(dāng)然了有很多針對(duì)mysql的監(jiān)控的工具，這些工具收集分析這些日志，變量等信息，提供很友好的界面顯示。

或許一個(gè)解決方案是把對(duì)同一個(gè) mysql 機(jī)器進(jìn)行訪問的所有的 dao 層
從各個(gè)微服務(wù)中抽出來，獨(dú)立操作做成一個(gè)微服務(wù)可以解決上述問題？
這樣的架構(gòu)奇怪嗎？

奇怪，有一些mysql的中間件提供連接池的功能，這樣就不需要再應(yīng)用中初始化連接池了，多個(gè)微服務(wù)公用一個(gè)連接池。

若相惜 回答

php .\artisan migrate --pretend
輸出sql瞧瞧, 看報(bào)錯(cuò)是索引長(zhǎng)度 問題吧.

玩控 回答

設(shè)置連接池，其實(shí)這也是連接池的使用場(chǎng)景。
MongoClient 就有帶這個(gè)功能。
配置連接池的最大連接數(shù)就好了。

夕顏 回答

從報(bào)錯(cuò)信息上可以看出，是books表和csessioninfo的排序規(guī)則不一致導(dǎo)致的。你可以修改 books 表，將排序規(guī)則改為utf8mb4_unicode_ci。

冷眸 回答

數(shù)據(jù)庫導(dǎo)出 mysqldump -uroot-proot play > D:/play.sql, 試一試
要不就是數(shù)據(jù)庫版本低.更新下數(shù)據(jù)庫.

首頁 上一頁 36 37 38 39 40 41 42 43 44 下一頁 尾頁