鍍金池/ 問答/ 數(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 每個fpm 處理請求數(shù)超過這個數(shù)就會重啟。應該是你們業(yè)務在那個時間段正好使得fpm請求數(shù)操作了閾值，造成fpm 進程同時重啟，可以處理請求的fmp數(shù)目只有少數(shù)，造成502。可以參考http://www.yunweipai.com/arch...

離人歸 回答

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

傲寒 回答

這種 IN中的語句確實不能像你那樣寫，無論如何@F_RepairDepartmentId0都被解釋為 單獨一個 字符串。
對于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(時間字段, '%Y-%m-%d') and DATE_FORMAT(時間字段, '%Y-%m-%d') < '2017-12-22'

澐染 回答

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

你的瞳 回答

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

茍活 回答

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

葬憶 回答

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

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

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

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

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

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

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

clipboard.png

菊外人 回答
下列代碼啟用，不取 model 文件，可以獲取到數(shù)據(jù)
不明白這部分是什么意思
catch證明PlantUnitModel.getPlantUnitModel().findAll這個Promise執(zhí)行了，所有錯誤應該是$ne，sequelize為了避免sql注入默認不能把$ne這類操作符當字符串處理。
怣人 回答 
const logoutByUser = await model.User.update(
    {last_login_ip: ipAt,last_sign_in_at: new Date()},
    {where: {id: id}}
)
兮顏 回答 
//文章的  評論的改一下表就好了
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. 授權
GRANT ALL PRIVILEGES ON shixiseng.* TO 'root'@'localhost' IDENTIFIED BY '1234567' WITH GRANT OPTION; 
2. 刷新
FLUSH PRIVILEGES;

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

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