在线观看不卡亚洲电影_亚洲妓女99综合网_91青青青亚洲娱乐在线观看_日韩无码高清综合久久

SELECT * FROM fs_info WHERE month=2 and (a<>0 OR b<>0 OR c<>0)

1.看你用的云服務(wù)器是啥系統(tǒng)，你可以理解為云就是一個操作系統(tǒng)，和你本地的Linux沒啥兩樣，你本地怎么放，云上就怎么放
2.云上的后端就沒辦法直接調(diào)試了，客戶端可以在瀏覽器里調(diào)試
3.ssh怎么用云服務(wù)器都有說明文檔

如果只是作為用戶唯一標(biāo)識的話，用MongoDB自己的ID生成策略挺好的，可以看看這本書。
如果涉及到mysql數(shù)據(jù)移植，那么寫一個移植程序也很簡單，建議就用MongoDB自帶的id.

如果要和老系統(tǒng)mysql兼容，那也可以就用mysql的id，但是你就得自己實現(xiàn)自增id了。

有沒有可能雙方同時主動斷開的？即雙方狀態(tài)轉(zhuǎn)換都是FIN_WAIT_1 -> CLOSING -> TIME_WAIT。

修飾符直接寫事件上好像就不能解除了，不過可以通過這樣方式實現(xiàn)你的需求

  <form v-on:submit="e => isPrevent && e.preventDefault()"></form>

isPrevent為true才觸發(fā)prevent

select * from t2 LEFT JOIN t1 ON t2. m_top_user_list like '%t1. user_id%'

php里運行mongodb的原生語句，用mongodb的語句才能去篩選objectId

如果實時性沒有要求的話可以用緩存做?；蛘呤褂卯惒讲樵兂鰜斫Y(jié)果后放到緩存中

下次記得把原始查詢也發(fā)出來，我們看著更方便些。從執(zhí)行計劃來反推，查詢大約是

db.webDevice.find({
    lid: {
        $in: [
            "40CnwyHkVmnA9kbScMLNLneaxuS4Tcj",
            "140CnwyHkVmnA9kbScMLNLneaxuS4Tcj"
        ]
    }
}).sort({createTime: -1}).limit(1);

因為命中索引，這個查詢獲取數(shù)據(jù)的速度實際上比較快，你也提到在一段時間內(nèi)第二次查詢就快了，這是一個很明顯的特點，代表內(nèi)存不足。MongoDB和其他數(shù)據(jù)庫一樣，都會使用空閑內(nèi)存緩沖索引和數(shù)據(jù)，當(dāng)內(nèi)存不足時就會使用LRU算法清理舊數(shù)據(jù)換入新數(shù)據(jù)再繼續(xù)查詢。因為這個過程涉及到磁盤數(shù)據(jù)交換，速度會大大降低。發(fā)生這種情況有一個特點，就是一段時間內(nèi)第二次執(zhí)行時速度就快了（因為數(shù)據(jù)已經(jīng)在內(nèi)存中）。但是如果過一段時間再執(zhí)行，速度又會變慢（因為又被換出內(nèi)存了）。所以你的情況實際上就是受限于硬件。
既然如此最直接的解決辦法就是：

1. 使用更快的硬盤；
2. 使用更大的內(nèi)存；

如果不能從硬件方面解決，有一點可以嘗試就是用CPU換內(nèi)存。做法是盡可能調(diào)小cacheSizeGB（是的沒錯，是調(diào)?。??？臻e出來的內(nèi)存操作系統(tǒng)會用來緩沖磁盤數(shù)據(jù)，而磁盤數(shù)據(jù)是經(jīng)過壓縮的，體積更小，因此可以緩沖更多數(shù)據(jù)到內(nèi)存中。但作為交換，在使用這些數(shù)據(jù)時需要經(jīng)過CPU再進(jìn)行一次解壓從而額外消耗CPU。即使這樣，效果也比從磁盤讀取要好很多。整個過程是自動進(jìn)行的，你需要做的只是調(diào)小cacheSizeGB。
這種做法可以在一定程度上緩解內(nèi)存不足的問題，但不是萬能的：

• 首先它會增加CPU消耗，如果你的系統(tǒng)本身已經(jīng)沒有剩余的CPU資源，這種做法就不合適；
• 其次受制于壓縮率，這樣做之后內(nèi)存能容納的數(shù)據(jù)并不會比以前多很多，所以并不是萬能的；

補(bǔ)充回答

基于你的新的疑問，以下幾點補(bǔ)充：

疑問1: 按照你說的方式調(diào)小cacheSizeGB,應(yīng)該怎么調(diào)整比較合理

我在上面有提到，這樣做的效果有限，是受制于壓縮率的限制。所以多容納的數(shù)據(jù)實際就是壓縮的數(shù)據(jù)。比如1G的內(nèi)存能放多少數(shù)據(jù)？

• 如果不壓縮（壓縮率100%），1G內(nèi)存能放1GB數(shù)據(jù)；
• 如果壓縮率90%，1G內(nèi)存可以放10/9GB~=1.11數(shù)據(jù)；
• 如果壓縮率80%，1G內(nèi)存可以放10/8 = 1.25GB數(shù)據(jù)；
• 以此類推……

所以調(diào)到多少，其實要看你想往內(nèi)存里放多少數(shù)據(jù)，而這往往是一個不確定的數(shù)值。這里會有另外一個概念叫做工作集（working set），就是你經(jīng)常用到的那些數(shù)據(jù)。比如你的數(shù)據(jù)庫共有100GB數(shù)據(jù)，但是你經(jīng)常用到的部分只有10GB，那么你的內(nèi)存只要能裝下10GB數(shù)據(jù)，應(yīng)用在大部分時候就可以非?？?，剩下的情況忽略就好了。
基于上面這些分析，你應(yīng)該可以算一下，你的工作集有多大，數(shù)據(jù)壓縮率有多大，那么需要把cacheSizeGB調(diào)到多小才能容納下工作集（又或者調(diào)到多小都不可能容納下工作集）。你的情況是內(nèi)存不足CPU空閑，所以如果懶得算，直接把cacheSizeGB調(diào)到最小值就好了。

疑問2: config只用了1.5GB內(nèi)存(限制了CacheSizeGB3GB).可以說明索引都加載到了內(nèi)存中嗎?

這說明config數(shù)據(jù)庫（元數(shù)據(jù)）的索引和數(shù)據(jù)都加載到內(nèi)存中了。注意數(shù)據(jù)的索引肯定是在shard中，與config無關(guān)。而且大頭是在shard上面。
順便提一下，如果不是實驗?zāi)康模緵]必要分這么多片。因為在一臺機(jī)器上分再多片，硬件資源也只有這么多，對于性能沒有什么意義，反而還會有額外的傳輸開銷。

疑問3: mongodb remove數(shù)據(jù)后,查詢卻越來越慢是什么情況?

remove之后跟查詢沒有本質(zhì)上的聯(lián)系，可能只是湊巧發(fā)生在一起。如果你有足夠的證據(jù)覺得這兩者確實有聯(lián)系，請另開問題描述清楚問題的上下文以及你發(fā)現(xiàn)的情況，必要的時候也可以求助于MongoDB JIRA。如果一定要做一個無根據(jù)的猜測，我覺得可能是remove時導(dǎo)致熱數(shù)據(jù)被換出內(nèi)存（注意remove也需要先找到滿足條件的數(shù)據(jù)然后才能刪除），引起后面的查詢需要重新從磁盤上加載數(shù)據(jù)造成的。

用

set names utf8

設(shè)置一下編碼試試

點最后一個按鈕

找到問題，每種編程語言都有規(guī)定字長。jsdouble類型字長超過15位之后的數(shù)值都不顯示歸零。

兩次JOIN

 SELECT p.*, c1.*
     FROM parent p
INNER JOIN child AS c1
       ON (p.id = c1.parent_id)
LEFT JOIN child AS c2
       ON (c1.parent = c2.parent_id and c1.createTime < c2.createTime )
    WHERE c2.createTime IS NULL

看場景：

1. 日志是否需要實時分析？

如果不需要實時分析，可以用文件形式，固定格式存儲，然后進(jìn)行離線分析。

1. 是否一直都需要所有日志？

如果不需要所有日志，只需要部分日志，那么可以給一定時間之前的日志刪掉。

現(xiàn)在一般的做法都是，近期日志存在mongodb這種數(shù)據(jù)庫中，長期日志存儲在大數(shù)據(jù)平臺。

先看看update時有沒有deadlock異常，再看下事物，多少條commit一次，再用show processlist等操作看看數(shù)據(jù)庫執(zhí)行的sql狀況。

如果字段都是一樣的話，可以考慮把多個結(jié)果集用union連起來，然后再排序

為什么數(shù)據(jù)庫查詢返回結(jié)果一定要符合你的格式要求呢？
這這個本身就是在你代碼業(yè)務(wù)層需要實現(xiàn)的功能?。?/p>

mysqli:

<?php

$timezone="Asia/Shanghai";
date_default_timezone_set($timezone);

$host="localhost";
$db_user="sucaishui";//數(shù)據(jù)庫帳號
$db_pass="123456";//數(shù)據(jù)庫密碼
$db_name="xiaochengxu";//數(shù)據(jù)庫名

$db = new mysqli($host, $db_user, $db_pass, $db_name);
if ($db -> connect_errno) {
    error_log('[連接失敗][ ' . $db -> connect_error . ' ]');
}
$db -> query('SET NAMES utf8');

PDO:

<?php

$timezone="Asia/Shanghai";
date_default_timezone_set($timezone);

$host="localhost";
$db_user="sucaishui";//數(shù)據(jù)庫帳號
$db_pass="123456";//數(shù)據(jù)庫密碼
$db_name="xiaochengxu";//數(shù)據(jù)庫名

$dsn = "mysql:dbname={$db_name};host={$host}";

try {
    $db = new PDO($dsn, $db_user, $db_pass);
} catch (PDOException $e) {
    error_log('[連接失敗][ ' . $e -> getMessage() . ' ]');
}
$db -> exec('SET NAMES utf8');

大概是這樣？

嗯，命令可以直接執(zhí)行的……

1. 最好先插入數(shù)據(jù)庫然后做性能測試再來考慮需不需要做額外優(yōu)化，如果要，可以用 redis 做緩沖。
2. 各類推送服務(wù)，蘋果有官方推送服務(wù)，安卓上有各家推送，小米、極光等等。