鍍金池/ 問答/ 數(shù)據(jù)庫問答
傻叼 回答

orderBy？

嫑吢丕 回答

是調(diào)用了toString。

Document.prototype.inspect = function(options) {
  var isPOJO = options &&
    utils.getFunctionName(options.constructor) === 'Object';
  var opts;
  if (isPOJO) {
    opts = options;
    opts.minimize = false;
  }
  return this.toObject(opts);
};

/**
 * Helper for console.log
 *
 * @api public
 * @method toString
 * @memberOf Document
 */

Document.prototype.toString = function() {
  return inspect(this.inspect());
};
未命名 回答

fpm 配置max_requests 每個(gè)fpm 處理請(qǐng)求數(shù)超過這個(gè)數(shù)就會(huì)重啟。應(yīng)該是你們業(yè)務(wù)在那個(gè)時(shí)間段正好使得fpm請(qǐng)求數(shù)操作了閾值，造成fpm 進(jìn)程同時(shí)重啟，可以處理請(qǐng)求的fmp數(shù)目只有少數(shù)，造成502?？梢詤⒖?a rel="nofollow noreferrer">http://www.yunweipai.com/arch...

離人歸 回答

因?yàn)樵趕egmentfault是第一次回答，在等待審核的過程中，查了查有關(guān)于mongodb的對(duì)于數(shù)據(jù)庫的安全驗(yàn)證相關(guān)的知識(shí)，發(fā)現(xiàn)我會(huì)出現(xiàn)這種collection為空的現(xiàn)象是因?yàn)槲耀@取的db也為空，對(duì)于數(shù)據(jù)庫的獲取為空也是因?yàn)槲覍?duì)數(shù)據(jù)庫開啟了安全驗(yàn)證的緣故。在DB_CONN_STR='mongodb://admin:admin@localhost:27017/MySite';//數(shù)據(jù)庫為MySite中所驗(yàn)證的用戶與密碼并不是我在這里需要的數(shù)據(jù)庫MySie的，所以報(bào)錯(cuò)，當(dāng)我使用role.db為MySite的用戶，數(shù)據(jù)庫就可以正常連接了

傲寒 回答

這種 IN中的語句確實(shí)不能像你那樣寫，無論如何@F_RepairDepartmentId0都被解釋為 單獨(dú)一個(gè) 字符串。
對(duì)于IN, 需要改成字符串拼接sql的形式，如下面這樣：

DECLARE @sql NVARCHAR(4000);
DECLARE @F_RepairDepartmentId0 NVARCHAR(3000);
SET @F_RepairDepartmentId0 = N'''ace7f0e7-f158-4587-920 D -e76546885198'', ''bf421a22-786b-40fd-8afc-c3e5e2364901'''；
SET @sql = N'SELECT *
                       FROM FC_Repair
                       WHERE
                         F_RepairDepartmentId IN
                         (' + @F_RepairDepartmentId0 + ')';

EXEC sp_executesql @sql

select * from 表名 where '2017-12-11'< DATE_FORMAT(時(shí)間字段, '%Y-%m-%d') and DATE_FORMAT(時(shí)間字段, '%Y-%m-%d') < '2017-12-22'

澐染 回答

hibernate的查詢是用query對(duì)象來進(jìn)行的，即Query query=session.createQuery(sql)，在對(duì)query遍歷或者直接轉(zhuǎn)list就行。

你的瞳 回答

...你看的沒有錯(cuò)，有個(gè)寫順序的文章，但我忘了所以就不妨上來了。一，先 from 確定你需求的字段，二，where 對(duì)數(shù)據(jù)進(jìn)行篩選，所以在性能提升方面，where 的作用很重要。而這是一個(gè)虛擬表就已經(jīng)生成了，而不存在你說的 having 時(shí)還沒有 d 這個(gè)列。

茍活 回答

就那串?dāng)?shù)據(jù)插入到一個(gè)臨時(shí)表中，然后執(zhí)行 inner join操作來查詢

葬憶 回答

對(duì)于參數(shù)綁定為何可以避免SQL注入，建議題主可以了解一下，值得注意的是prepare語句只能解析一條SQL，下面摘要說明一下prepare的作用：
首先從mysql服務(wù)器執(zhí)行sql的過程開始講起，SQL執(zhí)行過程包括以下階段 詞法分析->語法分析->語義分析->執(zhí)行計(jì)劃優(yōu)化->執(zhí)行。詞法分析->語法分析這兩個(gè)階段我們稱之為硬解析。詞法分析識(shí)別sql中每個(gè)詞，語法分析解析SQL語句是否符合sql語法，并得到一棵語法樹（Lex）。對(duì)于只是參數(shù)不同，其他均相同的sql，它們執(zhí)行時(shí)間不同但硬解析的時(shí)間是相同的。而同一SQL隨著查詢數(shù)據(jù)的變化，多次查詢執(zhí)行時(shí)間可能不同，但硬解析的時(shí)間是不變的。對(duì)于sql執(zhí)行時(shí)間較短，sql硬解析的時(shí)間占總執(zhí)行時(shí)間的比率越高。而對(duì)于淘寶應(yīng)用的絕大多數(shù)事務(wù)型SQL，查詢都會(huì)走索引，執(zhí)行時(shí)間都比較短。因此淘寶應(yīng)用db sql硬解析占的比重較大。

Prepare的出現(xiàn)就是為了優(yōu)化硬解析的問題。Prepare在服務(wù)器端的執(zhí)行過程如下

1） Prepare 接收客戶端帶”?”的sql, 硬解析得到語法樹(stmt->Lex), 緩存在線程所在的preparestatement cache中。此cache是一個(gè)HASH MAP. Key為stmt->id. 然后返回客戶端stmt->id等信息。

2） Execute 接收客戶端stmt->id和參數(shù)等信息。注意這里客戶端不需要再發(fā)sql過來。服務(wù)器根據(jù)stmt->id在preparestatement cache中查找得到硬解析后的stmt, 并設(shè)置參數(shù)，就可以繼續(xù)后面的優(yōu)化和執(zhí)行了。

Prepare在execute階段可以節(jié)省硬解析的時(shí)間。如果sql只執(zhí)行一次，且以prepare的方式執(zhí)行，那么sql執(zhí)行需兩次與服務(wù)器交互（Prepare和execute）, 而以普通（非prepare）方式，只需要一次交互。這樣使用prepare帶來額外的網(wǎng)絡(luò)開銷，可能得不償失。我們?cè)賮砜赐籹ql執(zhí)行多次的情況，比如以prepare方式執(zhí)行10次，那么只需要一次硬解析。這時(shí)候  額外的網(wǎng)絡(luò)開銷就顯得微乎其微了。因此prepare適用于頻繁執(zhí)行的SQL。

Prepare的另一個(gè)作用是防止sql注入，不過這個(gè)是在客戶端jdbc通過轉(zhuǎn)義實(shí)現(xiàn)的，跟服務(wù)器沒有關(guān)系。

建議題主看下MySQL官方文檔（https://dev.mysql.com/doc/ref...）。什么？看不懂英文？試試百度翻譯吧：https://fanyi.baidu.com

clipboard.png

菊外人 回答
下列代碼啟用，不取 model 文件，可以獲取到數(shù)據(jù)
不明白這部分是什么意思
catch證明PlantUnitModel.getPlantUnitModel().findAll這個(gè)Promise執(zhí)行了，所有錯(cuò)誤應(yīng)該是$ne，sequelize為了避免sql注入默認(rèn)不能把$ne這類操作符當(dāng)字符串處理。
怣人 回答 
const logoutByUser = await model.User.update(
    {last_login_ip: ipAt,last_sign_in_at: new Date()},
    {where: {id: id}}
)
兮顏 回答 
//文章的  評(píng)論的改一下表就好了
select tb_user.* from tb_article join tb_user on tb_user.id=tb_article.id order by tb_article.create_time desc limit 5;
//一起?效率...就沒怎么考慮233.....
SELECT
    a.uid,
    username
FROM
    (
        (
            SELECT
                `uid`,
                `create_time` AS `time`
            FROM
                tb_article
        )
        UNION ALL
            (
                SELECT
                    `uid`,
                    `create_time` AS time
                FROM
                    tb_comment
            )
    ) AS a
JOIN tb_userAS b ON a.uid = b.uid
GROUP BY
    a.uid
ORDER BY
    a.time DESC
LIMIT 5
朕略傻 回答 
1. 授權(quán)
GRANT ALL PRIVILEGES ON shixiseng.* TO 'root'@'localhost' IDENTIFIED BY '1234567' WITH GRANT OPTION; 
2. 刷新
FLUSH PRIVILEGES;

此處你得注意一點(diǎn)，你的hosts文件里面有沒有把127.0.0.1指向localhost

首頁 上一頁 116 117 118 119 120 121 122 123 124 下一頁 尾頁