你說(shuō)的是建表的字段么?我是在跨境電商公司上班,分享一下公司的商品表中的基本字段。
sku,商品的唯一標(biāo)識(shí),如一件白色的T恤
spu,同款sku的組合,如同款的T恤,有白色,藍(lán)色,黃色,紅色等
scu,多個(gè)sku的組合,如上衣和褲子一起賣(mài)
scpu,同款scu的組合,
price,長(zhǎng)描述,短描述(買(mǎi)點(diǎn)),可用庫(kù)存,倉(cāng)庫(kù)號(hào),銷(xiāo)售員,采購(gòu)員,商品類(lèi)名,商品圖片,
商品狀態(tài)(上架,下架,待發(fā)貨,待顧客反饋,待質(zhì)檢,等等一大堆)
還有好多,,,,數(shù)據(jù)庫(kù)用的是Mongodb,淘寶好像用的是Mysql,用的是他們自己家開(kāi)發(fā)的Druid 鏈接數(shù)據(jù)庫(kù)。
所有表都應(yīng)該有的,id,創(chuàng)建時(shí)間,更新時(shí)間,就不多說(shuō)了。
你把 servlet 的 method 與 HTML form 的 method(即 HTTP method) 混淆了,它們并沒(méi)有直接的關(guān)系。
而且 HTML form 的 method 屬性值只能是 get 或 post。
要實(shí)現(xiàn)自定義 HTTP method "LOGIN",你要在 servlet 添加處理 HTTP LOGIN method 的邏輯,如
// 重寫(xiě) HttpServlet.service() 以支持自定義 HTTP method。
package demo;
import javax.servlet.http.HttpServlet;
class CustomHttpServlet extends HttpServlet {
protected void service(HttpServletRequest req, HttpServletResponse resp) {
if (req.getMethod().toLowerCase() == "login") {
this.doLogin(req, res);
return;
}
super.service(req, resp);
}
protected void doLogin(HttpServletRequest req, HttpServletResponse resp) {
// 與 doGet() 類(lèi)似,在此處添加處理邏輯。
}
}
這時(shí)不能使用 HTML form 測(cè)試,應(yīng)該使用接口測(cè)試工具,發(fā)送類(lèi)似下面的請(qǐng)求
LOGIN http://127.0.0.1:8080/xxx
譬如
curl -X LOGIN http://127.0.0.1:8080/xxx
手寫(xiě)語(yǔ)句+注解,mysql Innodb 自己會(huì)加行級(jí)鎖,保證下面的語(yǔ)句線程安全,當(dāng)然 前提是你的 id 有索引
@Modifying
@Query("update products sc set quantity = quantity -1 where sc.id = ?")
public void UpdateById(@Param(value = "ids") String id);
這幾個(gè)字段都很小, 如果查詢條件相對(duì)固定的話,可以把這幾個(gè)字自段連一塊,形成一個(gè)字個(gè)段, 或物化視圖,并對(duì)此字段建索引. 然后只需查一個(gè)字段即可.
還有就是userid!=xxx, 最好改成(userid>xxx and userid<xxx), 也許我的經(jīng)驗(yàn)過(guò)時(shí)了, 但至少值得一試.
select date, count('字段') as '顯示的名字' , count('字段') as '顯示的名字' from `表` group by date
//date 表示 日期的字段名
({login, loading})=>({}) 這是一個(gè)函數(shù),和connect 函數(shù)的兩個(gè)參數(shù)不同,我應(yīng)該如何理解這個(gè)寫(xiě)法?
這是使用的第一個(gè)函數(shù)mapStateToProps(state, ownProps) ps: 兩個(gè)參數(shù)相對(duì)應(yīng)。
login:這個(gè)參數(shù)就是[models/login.js]里面,[reducers/changeLoginStatus]的返回值。
login和submitting這個(gè)怎么理解,是指綁定到submitting到組件的this.props里面嗎?
按資料說(shuō)法,這兩個(gè)都是要加到this.props上面的對(duì)象。
那么他是如何把src/models/login.js 里面的effects觸發(fā)的?
[models/login.js],應(yīng)該在聲明路由[common/router.js]的時(shí)候就已經(jīng)指定,
觸發(fā)應(yīng)該是用的[ruotes/User/Login.js]的[handleSubmit]
并且在組件中沒(méi)有看到如何方法調(diào)用submitting.
調(diào)用應(yīng)該是指這里[ruotes/User/Login.js]的[render]
loading.effects['login/login'] 這個(gè)方法應(yīng)該如何理解?
這個(gè)就是猜測(cè)了,應(yīng)該是返回的[model/login.js]下面[*login]的執(zhí)行狀態(tài),bool值。
感覺(jué)你現(xiàn)在做的是 藍(lán)圖 的形式。
先確定一下,你的兩個(gè)項(xiàng)目里的編譯器位置是否是同一個(gè),如果是同一個(gè),那么你就得設(shè)置藍(lán)圖。
JdbcTemplate
在IDEA
下使用的時(shí)候,有對(duì)SQL
語(yǔ)法校驗(yàn)的功能.
謝邀。
這個(gè)select count(*) from md_org 只是個(gè)查詢,和鎖沒(méi)有關(guān)系,沒(méi)有被鎖。
Rows:26553 是個(gè)粗略的統(tǒng)計(jì)數(shù)據(jù),并不保證準(zhǔn)確,具體的行數(shù)使用selct count(xxx)獲得。
如果查出來(lái)為0,就表示表中實(shí)際行數(shù)就是0了。
你的這種情況我還原下:
你開(kāi)啟事務(wù),然后不停的插入數(shù)據(jù),插入2萬(wàn)多條的數(shù)據(jù),這個(gè)時(shí)候show table status中的rows 就看到你插入的2萬(wàn)多條數(shù)據(jù),但是你不小心關(guān)掉了x掉了窗口,導(dǎo)致事務(wù)沒(méi)有提交,實(shí)際表中是沒(méi)有這些數(shù)據(jù)的(mysql 不會(huì)很智能的更新rows的條數(shù),它只是一個(gè)粗略的統(tǒng)計(jì)而已,沒(méi)有必要)。
建議單獨(dú)創(chuàng)建表保存最近聯(lián)系人。
1、從功能設(shè)計(jì)上看,最近聯(lián)系人是個(gè)獨(dú)立的功能,不依賴于聊天記錄,這一點(diǎn)你已經(jīng)說(shuō)過(guò)了。
2、從系統(tǒng)性能方面考慮,每次從聊天日志表從計(jì)算最近聯(lián)系人,數(shù)據(jù)量大的時(shí)候會(huì)存在性能瓶頸。
你說(shuō)的思路比較亂,先聚焦一下問(wèn)題:
如果是持續(xù)的寫(xiě)入壓力大,且超過(guò)單臺(tái)服務(wù)器磁盤(pán)IO寫(xiě)入能力,最簡(jiǎn)單的辦法就是mysql分為多個(gè)數(shù)據(jù)庫(kù),保證數(shù)據(jù)能分布不同的磁盤(pán)設(shè)備上,以提升寫(xiě)入的能力。
如果只是高峰期的寫(xiě)入壓力大,可以考慮讀寫(xiě)主要靠緩存的方案,后臺(tái)同步到數(shù)據(jù)庫(kù),但這樣對(duì)緩存的可用性、數(shù)據(jù)預(yù)熱方面的要求較高。
java方面的優(yōu)化,主要是提高接入能力,和后端數(shù)據(jù)庫(kù)是否能支持大數(shù)據(jù)寫(xiě)入沒(méi)關(guān)系。
無(wú)解???
1G內(nèi)存裝MySQl,就服你
不太明白PHP的做法,如果在Java內(nèi) 可以使用Mybatis中的ResultMap 組成一個(gè)聯(lián)合內(nèi)容的Bean類(lèi)實(shí)現(xiàn)
題外話,MongoDB歷史上出現(xiàn)過(guò)master/slave復(fù)制(其實(shí)現(xiàn)在也還存在)。嚴(yán)格地說(shuō),主備通常指的是那個(gè)東西。而我們現(xiàn)在用的基本上是復(fù)制集(replica set)。
再說(shuō)你這種情況,其實(shí)是正常的。原理跟你的磁盤(pán)用久了會(huì)有碎片是一個(gè)道理。特別是你曾經(jīng)大規(guī)模刪除過(guò)數(shù)據(jù)的情況下。簡(jiǎn)單地解釋下,假設(shè)你的表中有doc1/doc2/doc3/doc4一共4個(gè)文檔,在磁盤(pán)上的存儲(chǔ)順序是:
doc1|doc2|doc3|doc4
現(xiàn)在你刪除了doc2,磁盤(pán)上的空間使用情況變成:
doc1|(空白)|doc3|doc4
系統(tǒng)是沒(méi)有辦法釋放這個(gè)空白空間的,除非你進(jìn)行磁盤(pán)整理,把空白空間移到最后:
doc1|doc3|doc4|(空白)
然后系統(tǒng)才可以截?cái)辔募膊康目瞻?,釋放掉這個(gè)空間??梢钥闯鰜?lái),要把空白移動(dòng)到文件尾是個(gè)相當(dāng)費(fèi)時(shí)費(fèi)力的操作,最簡(jiǎn)單的辦法是:把后面所有的文檔順序前移來(lái)填補(bǔ)doc2留下的空白(如上所示doc3/doc4被前移)。但是這樣涉及到大量的磁盤(pán)I/O,會(huì)對(duì)性能造成嚴(yán)重影響。當(dāng)然不乏其他整理磁盤(pán)碎片的方法,但是無(wú)論哪一個(gè),都會(huì)造成比較嚴(yán)重的I/O影響,因此一般我們是不會(huì)進(jìn)行這樣的整理的。進(jìn)行碎片整理的方式就是:compact命令。如前所述,因?yàn)樗鼤?huì)對(duì)性能造成嚴(yán)重的影響,因此一般只會(huì)在維護(hù)時(shí)間進(jìn)行這個(gè)操作。而就算你不進(jìn)行這個(gè)操作,系統(tǒng)也知道哪些地方是空白的,在有新文檔進(jìn)來(lái)的時(shí)候,會(huì)嘗試重新使用這些空白的部分從而最大化空間利用率。只是,無(wú)論再好的算法,空間重復(fù)利用一定不可能是100%的,因?yàn)樾逻M(jìn)來(lái)的文檔永遠(yuǎn)沒(méi)有辦法正好跟之前被刪除的文檔一樣大,所以只能找一個(gè)比新文檔更大的空間來(lái)利用,這樣就會(huì)留下一個(gè)更小的、更難重復(fù)利用的碎片。
另外一種變通的方案是把節(jié)點(diǎn)內(nèi)容刪除,重新進(jìn)行一次同步。因?yàn)橥綍r(shí)相當(dāng)于把所有文檔全部抓取一遍,并一個(gè)接一個(gè)重新寫(xiě)到磁盤(pán)上,因此同步完成之后文檔在磁盤(pán)上是緊湊排列的,相當(dāng)于進(jìn)行了碎片整理。而且在這個(gè)過(guò)程中,受影響的是從節(jié)點(diǎn),它在同步過(guò)程中并不對(duì)外提供服務(wù),所以對(duì)線上的影響是最小的。但是注意,它同樣會(huì)對(duì)主節(jié)點(diǎn)造成影響,因?yàn)樗阎鞴?jié)點(diǎn)上的全部數(shù)據(jù)都讀一遍,主節(jié)點(diǎn)I/O升高是無(wú)法避免的。
最后回到你的問(wèn)題,為什么從節(jié)點(diǎn)比主節(jié)點(diǎn)小,上面應(yīng)該已經(jīng)解釋清楚了。
在mysql官網(wǎng)上看到的
On the other hand, you should not use mysql_use_result() for locking reads if you are doing a lot of processing for each row on the client side, or if the output is sent to a screen on which the user may type a ^S (stop scroll). This ties up the server and prevent other threads from updating any tables from which the data is being fetched.
select *,count(*) from A,B where A.cid = B.cid and A.uid = B.uid
用MongoDB的話,你題目中的數(shù)據(jù)結(jié)構(gòu)就可以很好地表達(dá)你需要的數(shù)據(jù)。
搜索出擁有 m 個(gè)“屠龍寶刀” 和 n 個(gè)“無(wú)盡之刃”的賬號(hào)。
這個(gè)搜索可以用:
db.table.find({
$and:[
{data: {$elemMatch: {name: '屠龍寶刀', num: m}}},
{data: {$elemMatch: {name: '無(wú)盡之刃', num: n}}},
]
});
為了查詢更快,需要索引:
db.table.createIndex({"data.name": 1, "data.num": 1});
因?yàn)樵贛ysql里,整數(shù)0與空串''做等于比較的時(shí)候,結(jié)果為真,你需要把
b.post_status = ''
改為
CAST(b.post_status AS CHAR) = ''
你可以再看看文檔Comparison Functions and Operators。
北大青鳥(niǎo)APTECH成立于1999年。依托北京大學(xué)優(yōu)質(zhì)雄厚的教育資源和背景,秉承“教育改變生活”的發(fā)展理念,致力于培養(yǎng)中國(guó)IT技能型緊缺人才,是大數(shù)據(jù)專(zhuān)業(yè)的國(guó)家
北大青鳥(niǎo)中博軟件學(xué)院創(chuàng)立于2003年,作為華東區(qū)著名互聯(lián)網(wǎng)學(xué)院和江蘇省首批服務(wù)外包人才培訓(xùn)基地,中博成功培育了近30000名軟件工程師走向高薪崗位,合作企業(yè)超4
中公教育集團(tuán)創(chuàng)建于1999年,經(jīng)過(guò)二十年潛心發(fā)展,已由一家北大畢業(yè)生自主創(chuàng)業(yè)的信息技術(shù)與教育服務(wù)機(jī)構(gòu),發(fā)展為教育服務(wù)業(yè)的綜合性企業(yè)集團(tuán),成為集合面授教學(xué)培訓(xùn)、網(wǎng)
達(dá)內(nèi)教育集團(tuán)成立于2002年,是一家由留學(xué)海歸創(chuàng)辦的高端職業(yè)教育培訓(xùn)機(jī)構(gòu),是中國(guó)一站式人才培養(yǎng)平臺(tái)、一站式人才輸送平臺(tái)。2014年4月3日在美國(guó)成功上市,融資1
曾工作于聯(lián)想擔(dān)任系統(tǒng)開(kāi)發(fā)工程師,曾在博彥科技股份有限公司擔(dān)任項(xiàng)目經(jīng)理從事移動(dòng)互聯(lián)網(wǎng)管理及研發(fā)工作,曾創(chuàng)辦藍(lán)懿科技有限責(zé)任公司從事總經(jīng)理職務(wù)負(fù)責(zé)iOS教學(xué)及管理工作。
浪潮集團(tuán)項(xiàng)目經(jīng)理。精通Java與.NET 技術(shù), 熟練的跨平臺(tái)面向?qū)ο箝_(kāi)發(fā)經(jīng)驗(yàn),技術(shù)功底深厚。 授課風(fēng)格 授課風(fēng)格清新自然、條理清晰、主次分明、重點(diǎn)難點(diǎn)突出、引人入勝。
精通HTML5和CSS3;Javascript及主流js庫(kù),具有快速界面開(kāi)發(fā)的能力,對(duì)瀏覽器兼容性、前端性能優(yōu)化等有深入理解。精通網(wǎng)頁(yè)制作和網(wǎng)頁(yè)游戲開(kāi)發(fā)。
具有10 年的Java 企業(yè)應(yīng)用開(kāi)發(fā)經(jīng)驗(yàn)。曾經(jīng)歷任德國(guó)Software AG 技術(shù)顧問(wèn),美國(guó)Dachieve 系統(tǒng)架構(gòu)師,美國(guó)AngelEngineers Inc. 系統(tǒng)架構(gòu)師。